Способи представлення вимог

· Документація, в якій використовується чітко структурована і акуратно використовувана природна мова

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

· Формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов.

Результат розробки вимог – задокументована угода між клієнтами і розробниками про створюваний продукт.

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

Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.

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

Специфікація вимог до ПЗ необхідна різним учасникам проекту:

1. Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт

2. Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси

3. Команді розробників ПЗ – отримує представлення про створюваний продукт

4. Групі тестування – складає плати тестування, варіанти використання і процедури.

5. Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту

6. Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу

7. Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів

8. Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.

Основні питання, що розглядаються SRS:

1. Функціональні можливості. Які передбачувані функції ПЗ?

2. Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?

3. Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?

4. Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?

5. Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?

Переваги і використання SRS

Документ SRS – однозначний і повний результат процесу специфікації інформаційної системи. Грамотно складений документ SRS надає наступні основні можливості:

Для замовника: точний опис того, що він хоче отримати

Для розробника: однозначне тлумачення і розуміння того, що хоче отримати замовник.

Мета розробки – надати замовнику, розробнику іншим учасникам проекту ряд переваг:

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

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

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

· Забезпечити основу для контролю якості розроблюваного продукту. Учасники проекту при використанні СРС можуть складати плани контролю якості, тестування і прийому більш ефективно.

· Полегшити розгортання та тиражування системи. СРС робить більш просту передачу ІС новим користувачам або її установку

· Служить в якості основи для розширення. Оскільки в СРС обговорюється сама ІС, а не проект, за яким вона розроблена, СРС служить основою для подальшого розширення готової системи.

27.03.2012 Лекція: Специфікація вимог до ПЗ

Характеристики правильно складеної спеки

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

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

Повнота (завершеність). Спека є повною, якщо вона включає наступні елементи:

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

· Визначення відгуків ПЗ на всі класи вхідних даних, які можуть бути реалізовані, в усіх можливих ситуаціях.

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

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

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

Двома типами ймовірних конфліктів в спеці є наступні:

· Можуть входити в конфлікт задані характеристики реальних об’єктів. Наприкла, (одна вимога може встановлювати, що всі індикатори мають бути зеленими, у той час як в іншій може бути зазначено, що всі індикатори повинні бути синіми).

· Між двома заданими діями може існувати логічний або тимчасовий поті. Наприклад, одна вимога може встановлювати, що «А» повинно завжди слідувати за «Б», в той час як інша може вимагати, щоб події «А» і «Б» відбувалися одночасно.

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

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

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

1. Замовникам більш ретельно розглянути вимогу, що часто дозволяє роз’яснити будь-які приховані припущення, які можуть бути укладені в них.

2. Розробникам прийняти правильні проектні рішення, прикласти відповідні зусилля до різних складових програмного вибору.

Ступінь необхідності. Другий спосіб впорядкування вимог полягає в том, що б розрізняти класи вимог як необхідні, умовні і необов’язкові.

1. Необхідні. Припускають, що ПЗ не буде придатним, якщо ці вимоги не будуть забезпечені узгодженим чином.

2. Умовні. Припускають, що ці вимоги розширяють ПП, але не зроблять його непридатним за їх відсутності.

3. Необов`язкові. Припускають клас функцій, які можуть заслуговувати або не заслуговувати на увагу. Це дає постачальнику можливість запропонувати що-небудь, що виходить за межі спеки.

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

Неперевіряємі вимоги включають формулювання типу «працює добре», «гарний інтерфейс з користувачем» і «зазвичай має відбуватися». Ці вимоги не можуть бути перевірені.

Прикладом перевіряє мого твердження є наступне: Вихідні дані програми повинні вироблятися в межах 20 секунд протягом 60% часового інтервалу подій і повинні вироблятися в межах 30 секунд протягом 100% часового інтервалу подій.

Якщо не можна винайти метод, щоб визначити відповідає ПЗ певній вимозі, то цю вимогу слід виключити.

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

Якщо правило кодифікованість вимагає, щоб спека:

1. Мала зв’язану і легку у використанні структуру зі змістом, алфавітним покажчиком.

2. Не була надмірною (тобто, одна і та ж вимога не повинна з`являтися в спеці більше ніж в одному місці).

3. Висловлювала кожну вимогу роздільно, не змішуючи її х іншими вимогами.

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

Рекомендуються наступні два типи відслідковуваності:

1. Зворотня відслідковуваність (до попередніх стадій розробки). Залежить від кожної вимоги, яке в явному вигляді посилається на її джерело в більш ранніх документах.

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

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

Шаблон специфікації вимог до ПЗ

Кожна організація, що спеціалізується на розробці ПЗ, повинна прийняти один або кілька стандартних шаблонів спеки для використання в проектах. Доступні різні шаблоки спеки (Девиса, Робертсона і т.д.).

Складові специфікації вимог:

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

1.1.Призначення (визначається продукт або застосування, для якого розробляється дана спека; редакція або номер випуску)

1.2.Угоди, прийняті в документах (необхідно описати всі стандарти, включаючи стилі тексту, особливості виділення або зауваження)

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

1.4.Границі проекту (описується ПЗ і його призначення, коротко. Тут потрібно показати, як продукт пов'язаний із бізнес цілями і стратегіями даного підприємства)

1.5.Посилання (перерахувати всі документи, на які посилається спека (контракти, стандарти та інші).

2. Загальний опис (представляється загальний опис продукту і середовища застосування даного ПЗ, користувальницька аудиторія, обмеження, припущення і залежності)

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

2.2.Особливості продукту (перелік основних особливостей продукту або його головних функцій, детальніше функції будуть розписані в п.3; варто проілюструвати основні групи вимог і їх взаємовідношення (діаграму потоків даних і варіантів використання))

2.3.Класи і характеристики користувачів (визначення різноманітних класів користувачів, які працюватимуть з ПП і опис їхніх характеристик (адмін., юзер, гість і т.д.))

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

2.5.Обмеження дизайну і реалізації (зазначається опис будь яких факторів, які обмежують можливості доступні розробникам, логічні обґрунтування кожного положення та інше. Обмеження: визначені технології, засоби, мови програмування і БД, які варто використовувати або уникати; обмеження пов’язані з обладнанням; зворотна сумісність з продуктами, що випущені раніше)

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

2.7.Припущення і залежності

3. Функції системи

3.1.Функція системи Х

3.1.1. Опис і пріоритети

3.1.2. Послідовності «вплив-реакція»

3.1.3. Функціональні вимоги

04.04.2012 ТЗ та перевірка вимог

ТЗ – вихідний документ для розробки автоматизованої системи, створення ПП, відповідно до якого проводиться виготовлення, приймання при введенні в дію та експлуатація відповідного об’єкта.

Документ ТЗ регламентовано стандартами:

1. ГОСТ 19.201-78 «Технічне завдання, вимоги до змісту та оформлення»

2. ГОСТ 34.602-89 «Технічне завдання на створення автоматизованої системи» - є актуальним і до сьогодні.

Згідно з ГОСТ 34.602-89 ТЗ є основним документом, що визначає вимоги і порядок створення (розвитку або модернізації) інформаційної системи, відповідно до якого проводиться її розробка і приймання при введені в дію.

Згідно з діючими стандартами, ТЗ повинно включати в себе такі розділи, які можуть бути розділені на підрозділи:

1. Загальні відомості

2. Призначення та мета створення(розвитку) системи

3. Характеристика об’єктів автоматизації

4. Вимоги до системи

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

6. Порядок контролю і приймання системи

7. Вимоги до складу і змісту робіт з підготовки об’єкт автоматизації введення системи в дію

8. Вимоги до документування

9. Джерела розробки

Далі деталізація змісту вище зазначених розділів (на російській мові, із ГОСТу):

2.3. В разделе «Общие сведения» указывают:

· 1) полное наименование системы и ее условное обозначение;

· 2) шифр темы или шифр (номер) договора;

· 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

· 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

· 5) плановые сроки начала и окончания работы по созданию системы;

· 6) сведения об источниках и порядке финансирования работ;

· 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

· 1) назначение системы;

· 2) цели создания системы.

2.4.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.

2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

2.5. В разделе «Характеристики объекта автоматизации» приводят:

· 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

· 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:

· 1) требования к системе в целом;

· 2) требования к функциям (задачам), выполняемым системой;

· 3) требования к видам обеспечения.

2.6.1. В подразделе «Требования к системе в целом» указывают:

· требования к структуре и функционированию системы;

· требования к численности и квалификации персонала системы и режиму его работы;

· показатели назначения;

· требования к надежности;

· требования безопасности;

· требования к эргономике и технической эстетике;

· требования к транспортабельности для подвижных АС;

· требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

· требования к защите информации от несанкционированного доступа;

· требования по сохранности информации при авариях;

· требования к защите от влияния внешних воздействий;

· требования к патентной чистоте;

· требования по стандартизации и унификации;

· дополнительные требования.

2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:

 1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

 2) временной регламент реализации каждой функции, задачи (или комплекса задач);

 3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;

 4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

2.7. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

2.8. В разделе «Порядок контроля и приемки системы» указывают:

• 1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
• 2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
• З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

2.9. В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие.

В перечень основных мероприятий включают:

• 1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
• 2) изменения, которые необходимо осуществить в объекте автоматизации;
• 3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
• 4) создание необходимых для функционирования системы подразделений и служб;
• 5) сроки и порядок комплектования штатов и обучения персонала.

2.10. В разделе «Требования к документированию» приводят:

• 1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика;
  перечень документов, выпускаемых на машинных носителях;
  требования к микрофильмированию документации;
• 2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
• 3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

2.11. В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

18.04.2012 Перевірка вимог

· Проблемні ситуації процесу формування і оцінки вимог;

· Методи і засоби перевірки вимог.

Властивості коректних вимог

Як здійснити перевірку готової системи (або її процесу створення)?

1. Впевнитись, що система відповідає сформульованим вимогам

2. Впевнитись, що система дійсно працює

Вимоги повинні задовольняти наступним властивостям: повноті, ясності, коректності, узгоджуваності, перевіряємості і т.д.

Крім того варто впевнитись в тому, що:

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

2. Вимоги до ПЗ точно відображають системні вимоги, бізнес-правила.

3. Вимоги забезпечують якісну основу для проектування і збірки ПЗ.

Проблемні ситуації:

1. Двозначність. Ситуація, коли одну вимогу можна інтерпретувати більше ніж в одному значенні.

2. «Золочення» продукту – такі ситуації, коли розробники додають функції, яких немає в специфікації, але їм здається, що це сподобається користувачам. Але замовнику може це не сподобатись.

3. Мінімальна специфікація – представлення вимог на 2-3 сторінках (у невеликих проектах). Мінімальне спека доречна, якщо має місце наявність одночасно трьох обставин:

a. Ціна контракту і розміри проекту настільки малі, що розробляти повну спеку є дорогим задоволенням.

b. Колектив розробника володіє достатнім ступенем досвіду виконання проектів у суміжних областях

c. Між замовником та розробником існують конструктивні відносини і обидві сторони розуміють і приймають ризики міні-специфікації.

Методи і засоби перевірки вимог розрізняють за параметрами:

1. За широтою аналізу – перегляд (вибіркова перевірка)

2. За ступенем формалізації – неофіційні процедури, процедури, що проводяться за формальними правилами (інспекції, експертизи).

3. За складом групи перевірки – з (без) участю автора, з (без) участі менеджера проекту, з (без) участю представників зовнішніх організацій.

4. За використовуваними засобами – тексти вимог, тестові сценарії, критерії прийнятності, прототип.

Неофіційні перегляди вимог:

1. Перегляди «за столом» (коли перевірку робить колега по роботі)

2. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

3. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

У третьому випадку автор здійснює презентацію розроблених ним вимог на параді з подальшим обговоренням.

Офіційна перевірка вимог:

На відміну від неофіційних переглядів, офіційна перевірка представляє собою суворо регламентований процес. По його завершенню формується звіт, в якому вказуються матеріали, рецензенти (ті, хто буде оцінювати продукт – експерт) і думка команди рецензентів про прийнятність продукту.

Головний результат – сукупність усіх знайдених дефектів і піднятих питань.

Експертиза як метод перевірки вимог (інспекція):

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

Учасники:

1. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

2. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

3. Люди, що виконують роботу, що базуються на перевіряємому елементі.

4. Люди, що відповідають за роботу продуктів, що взаємодіють з перевіряємим елементом. Вони виявляють проблеми з вимогами до зовнішнього інтерфейсу. Також модуть виявити вимоги, зміна яких в перевіряє мій спеці впливає на інші системи.

Проблеми перевірки:

1. Великий об’єм документації

2. Велика команда експертів (бажано не більше шести)

3. Географічній роздій інспекторів (доводиться зв’язуватись по відео або пошті)

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

Ролі експертів:

1. Автор. Створює та підтримує продукт, що перевіряється. Тобто аналітик, що розробляв спеку.

2. Координатор – керівник перевірки, планує експертизу сумісно з автором, погоджує особливості і організовує нараду.

3. Читач. Один із перевіряючих виступає в ролі читача. На нараді він перефразовує положення спеки – по одній вимозі за раз.

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

Рішення про завершення експертизи приймається відповідно до одного (будь-якого) з трьох критеріїв:

1. Прийняття з відсутністю або малою необхідністю переробки

2. Прийняття з перевіркою перероблених фрагментів.

3. Необхідність повторної експертизи.

Дата добавления: 2015-09-06