Сутність, структура та принципи життєвого циклу ІС обліку

Поняття життєвого циклу ІС обліку (ЖЦ ІСО) та їхнього ПЗ є одним з базових у програмній інженерії. Життєвий цикл АІС визначається як період часу, що починається з моменту ухвалення рішення про необхідність створення АІС і закінчується в момент його повного вилучення з експлуатації.

Упродовж усього життєвого циклуІС обліку використовують наступні принципи: системність, стандартизація та уніфікація, суміс­ність, розвиток, ефективність.

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

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

Системний підхід та моделювання дозволяють у доступній формі відображати всі необхідні дані, а також використовувати ПК для до­слідження поведінки системи в конкретних експериментальних умовах.

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

Цей принцип дозволяє скоротити термін впровадження автоматизованої інформаційної системи обліку, а також трудові та вартісні витрати на створення цієї системи.

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

Цей принцип дозволяє забезпечу­вати нормальне функціонування економічних об'єктів, підвищувати ефективність управління підприємством.

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

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

Життєвий цикл утворюють процеси. Основним нормативним документом, що регламентує склад процесів ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Міжнародна організація зі стандартизації, ІЕС - International Electrotechnical Commission - Міжнародна комісія з електротехніки).

Він визначає структуру ЖЦ, що містить процеси, дії та задачі, які потрібно виконати під час створення ПЗ АІС. У цьому стандарті:

· ПЗ (або програмний продукт) визначається як набір комп'ютерних програм, процедур, пов'язаної з ними документації та даних;

· процес визначається як сукупність взаємозалежних дій, що перетворять деякі вхідні дані на вихідні. Кожен процес характеризується певними задачами й методами їх розв'язування, вихідними даними, отриманими від інших процесів, і результатами.

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

Зауважимо, що в Україні, як у частині Радянського Союзу, створення АІС та їхнього ПЗ з початку 1970-х pp. регламентувалося стандартами ДСТ ЄСПД (Єдиної системи програмної документації — серія ДСТ 19.XXX), що були орієнтовані на клас досить простих систем невеликого обсягу, створюваних окремими програмістами.

Нині в Україні процеси створення АІС, до складу яких входить і ПЗ, регламентуються нормативно-правовими документами, пов'язаними з реалізацією Національної програми інформатизації, а також двома стандартами, що визначають технологію створення таких систем: ГОСТ 34 «Комплекс стандартів на автоматизовані системи» і ДСТУ 3918-1999 «Інформаційні технології. Процеси життєвого циклу програмного забезпечення». Проблема вибору одного з них вирішується під час узгодження ТЗ на систему.

Відповідно до стандарту ISO/IEC 12207 усі процеси ЖЦ АІС розділені на три групи:

1) п'ять основних процесів (придбання, постачання, розроблення, експлуатація, супроводження);

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

3) чотири організаційні процеси (управління, створення інфраструктури, удосконалювання, навчання).

Основні процеси ЖЦ ПЗ

До основних процесів ЖЦ ПЗ належать таки процеси, як: придбання, постачання, розроблення, експлуатації, супроводження.

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

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

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

Підготовка і коригування договору охоплюють такі задачі:

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

· вибір конкретного постачальника на основі аналізу пропозицій;

· підготовка й укладання договору з постачальником;

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

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

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

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

Процес постачання (supply process) охоплює дії, виконувані постачальником, котрий постачає замовнику компоненти АІС, програмний продукт або послугу. Цей процес передбачає такі дії: ініціювання постачання; підготовка відповіді на заявочні пропозиції; підготовка договору; планування; виконання і контроль; перевірка й оцінювання; постачання і завершення робіт.

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

Планування охоплює такі задачі:

· ухвалення рішення постачальником щодо виконання робіт самотужки або із залученням субпідрядника;

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

Процес розроблення (development process) передбачає дії, що виконуються розробником, і охоплює роботи зі створення АІС і її компонентів відповідно до заданих вимог, включаючи оформлення проектної й експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності та відповідної якості програмних продуктів, підготовку матеріалів, необхідних для організації навчання персоналу тощо.

До процесу розроблення входять наступні дії:

· підготовча робота;

· аналіз вимог до АІС;

· проектування архітектури АІС;

· аналіз вимог до ПЗ АІС;

· проектування архітектури ПЗ;

· детальне проектування ПЗ;

· кодування і тестування ПЗ;

· інтеграція ПЗ;

· кваліфікаційне тестування ПЗ;

· інтеграція системи;

· кваліфікаційне тестування системи;

· установлення і приймання ПЗ АІС;

· приймання АІС.

Підготовча робота розпочинається з вибору моделі ЖЦ АІС, Що відповідає масштабу, значущості і складності проекту. Дії і задачі процесу розроблення мають відповідати обраній моделі. Розробник повинен вибрати, адаптувати до умов проекту і використовувати погоджені з замовником стандарти, методи і засоби розроблення, а також скласти план виконання робіт.

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

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

Аналіз вимог до АІС припускає визначення таких характеристик для кожного компонента:

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

· зовнішніх інтерфейсів;

· специфікацій надійності та безпеки;

· ергономічних вимог;

· вимог до використовуваних даних;

· вимог до встановлення і приймання;

· вимог до документації для користувачів;

· вимог до експлуатації та супроводження.

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

Проектування архітектури ПЗ охоплює такі задачі (для кожного компонента ПЗ):

· трансформація вимог до ПЗ в архітектуру, що визначає на високому рівні структуру ПЗ і склад його компонентів;

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

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

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

Архітектура компонентів ПЗ має відповідати вимогам, які висувають до них, а також прийнятим проектним стандартам і методам.

Детальне проектування ПЗ містить такі задачі:

· опис компонентів ПЗ та інтерфейсів між ними на нижчому рівні, достатньому для їх подальшого самостійного кодування й тестування;

· розробка й документування детального проекту бази даних;

· відновлення (у разі потреби) документації для користувачів;

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

· коригування плану інтеграції ПЗ.

Кодування і тестування ПЗ охоплюють такі задачі:

· розробка (кодування) і документування кожного компонента ПЗ і бази даних, а також сукупності тестових процедур і даних для їх тестування;

· тестування кожного компонента ПЗ і бази даних на відповідність вимогам. Результати тестування компонентів мають бути документовані;

· коригування (за потреби) документації для користувачів;

· коригування плану інтеграції ПЗ.

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

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

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

При цьому також перевіряють повноту технічної документації і документації для користувачів на її адекватність самим компонентам ПЗ.

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

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

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

Процес експлуатації (operation process) охоплює дії оператора - організації, що експлуатує систему. Цей процес передбачає такі дії, як: підготовча робота; експлуатаційне тестування; експлуатація системи; підтримка користувачів.

Підготовча робота охоплює вирішення оператором таких задач:

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

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

Експлуатаційне тестування здійснюють для кожної чергової редакції програмного продукту, після чого її передають в експлуатацію.

Експлуатація системи виконується в призначеному для цього середовищі відповідно до документації для користувачів.

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

Процес супроводження (maintenance process) передбачає дії, виконувані супровідною організацією (службою супроводження). Цей процес активізується у разі змін (модифікацій) АІС, програмного продукту і відповідної документації, викликаних виниклими проблемами чи потребами в модернізації чи адаптації АІС і відповідного ПЗ. Відповідно до стандарту ІЕЕЕ-90 під супроводженням розуміють внесення змін до ПЗ з метою виправлення помилок, підвищення продуктивності або адаптації до умов роботи, що змінилися, або вимог.

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

Процес супроводження охоплює такі дії:

· підготовча робота;

· аналіз проблем і запитів на модифікацію ПЗ і системи в цілому;

· модифікація відповідних компонентів АІС і ПЗ;

· перевірка і приймання;

· перенесення ПЗ в інше середовище;

· зняття АІС і ПЗ з експлуатації.

Підготовча робота служби супроводження охоплює такі задачі:

· планування дій і робіт, що виконуються у процесі супроводження;

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

Аналіз проблем і запитів на модифікацію АІС та її ПЗ, виконуваний службою супроводження, містить такі задачі:

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

- тип (коригування, поліпшення, профілактика або адаптація до нового середовища);

- масштаб (розміри модифікації, вартість і час її реалізації);

- критичність (вплив на продуктивність, надійність або безпеку);

· оцінка доцільності проведення модифікації і можливих варіантів її проведення;

· затвердження обраного варіанта модифікації.

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

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

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

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

Допоміжні процеси ЖЦ АІС

Процес документування (documentation process)

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

Процес документування охоплює такі дії:

· підготовчу роботу;

· проектування й розроблення документації;

· випуск документації;

· супроводження документації.

Процес керування конфігурацією (configuration management process)

Процес припускає застосування адміністративних і технічних процедур упродовж усього ЖЦ АІС для визначення стану компонентів системи, керування модифікаціями, опису й підготовки звітів щодо стану компонентів АІС і запитів на модифікацію, забезпечення повноти, сумісності й коректності компонентів, керування збереженням і постачанням компонентів АІС. Відповідно до стандарту ІЕЕЕ-90 під конфігурацією ПЗ розуміють сукупність його функціональних і фізичних характеристик, установлених у технічній документації та реалізованих у ПЗ. Те саме можна сказати про АІС загалом.

Керування конфігурацією дає змогу організувати, систематично враховувати й контролювати внесення змін у АІС на всіх стадіях ЖЦ. Процес керування конфігурацією передбачає такі дії:

· підготовчу роботу;

· ідентифікацію конфігурації;

· контроль конфігурації;

· відстежування стану конфігурації;

· оцінювання конфігурації;

· керування випуском і постачанням.

Підготовча робота полягає в плануванні керування конфігурацією.

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

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

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

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

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

Оцінювання конфігурації полягає в оцінюванні функціональної повноти компонентів АІС, а також відповідності їхнього фізичного стану поточному технічному опису.

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

Процес забезпечення якості (quality assurance process)

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

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

Процес забезпечення якості охоплює такі дії:

· підготовчу роботу;

· забезпечення якості продукту;

· забезпечення якості процесу;

· забезпечення інших показників якості системи.

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

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

Забезпечення якості процесу передбачає гарантування відповідності процесів ЖЦ, методів розроблення, середовища розробки і кваліфікації персоналу умовам договору, установленим стандартам і процедурам.

Забезпечення інших показників якості системи здійснюється відповідно до умов договору і стандарту якості ISO 9001.

Процес верифікації (verification process)

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

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

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

Процес верифікації охоплює підготовчу роботу і власне верифікацію.

У процесі верифікації перевіряють такі умови:

· несуперечність вимог до системи і ступінь обліку потреб користувачів;

· можливості постачальника виконати задані вимоги;

· відповідність обраних процесів ЖЦ умовам договору;

· адекватність стандартів, процедур і середовища розробки процесам ЖЦ;

· відповідність проектних специфікацій заданим вимогам;

· коректність опису в проектних специфікаціях вхідних і вихідних даних, послідовності подій, інтерфейсів, логіки тощо;

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

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

· коректність інтеграції компонентів АІС у систему;

· адекватність, повнота й несуперечливість документації.

Процес атестації (validation process)

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

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

Процес атестації охоплює підготовчу роботу і власне атестацію.

Процес спільного оцінювання (joint review process)

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

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

Процес спільного оцінювання охоплює такі дії:

· підготовчу роботу;

· оцінювання керування проектом;

· технічне оцінювання.

Процес аудиту (audit process)

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

Аудит - це ревізія (перевірка), проведена компетентним органом (особою) з метою забезпечення незалежної оцінки ступеня відповідності АІС і процесу її розроблення встановленим вимогам. Аудит слугує для встановлення відповідності реальних робіт 1 звітів вимогам, планам і контракту. Аудитори (ревізори) не повинні безпосередньо залежати від розробників АІС. Вони визначають стан робіт, використання ресурсів, відповідність документації специфікаціям і стандартам, коректність тестування. Дії в процесі аудиту охоплюють підготовчу роботу і власне аудит.

Процес розв'язування проблем (problem resolution process)

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

Кожну виявлену проблему потрібно ідентифікувати, описати, проаналізувати й розв'язати.

Процес розв'язування проблем охоплює підготовчу роботу і власне розв'язування проблем.

• ⇐ Назад
• 11
• 12
• 13
• 14
• 15
• 16
• 171819
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• Далее ⇒