Зміст
ВСТУП
Введення в CASE - технології.
Введення в предмет діяльності.
1. Яка використовується нотація
2. Представлення моделі
3. Специфікації процесів діяльності з цінними паперами
3.1. Пасивна діяльність з цінними паперами
3.1.1.Операціі з векселями
3.1.2.Операціі з депозитними сертифікатами
3.2. Активна діяльність з цінними паперами
3.2.1. Операції з ДКО
3.2.2. Операції з КВ
3.2.3. Операції з ВО
Додаток 1. Діаграми потоків даних
Додаток 2. Концептуальні засади CASE - технології
Додаток 3. Цінні папери
П.3.1. Класифікація цінних паперів
П.3.2. Регулювання ринку цінних паперів.

ВСТУП

Лавиноподібне розширення областей застосування ЕОМ, зростаюча складність програмного забезпечення і підвищується до нього вимоги призвели до необхідності індустріалізації виробництва програмної продукції, а саме: необхідність застосування високоефективних технологій створення програмного забезпечення. Важливий напрямок у розвитку програмних технологій склали розробки інтегрованих інструментальних систем, що базуються на концепціях життєвого циклу і управління якістю програмної продукції і, що представляють собою комплексні технології, орієнтовані на створення складних програмних систем і підтримку їх повного життєвого циклу або ряду його основних етапів. Подальший розвиток робіт в даному напрямку привело до створення ряду концептуально цілісних, оснащених високорівневим засобами проектування і реалізації, доведених по якості і легкості тиражування до рівня програмних продуктів технологічних систем, які і отримали назву CASE - систем або CASE - технології.
В даний час CASE - системи міцно увійшли в практику програмної індустрії. При цьому вони використовуються не тільки як комплексні технологічні конвеєри для виробництва програмних систем, а й як потужний інструмент вирішення дослідницьких і проектних завдань, таких як структурний аналіз предметної області, специфікація проектів засобами мов програмування четвертого покоління, випуск проектної документації, тестування реалізацій проектів, планування і контроль розробок, моделювання ділових програм з метою вирішення задач оперативного і стратегічного планування та управління ресурсами тощо
У цій роботі ми спробували дати опис одного з основних методів структурного аналізу і проектування програмного забезпечення систем обробки інформації, найбільш поширеним способом - діаграмами потоків даних. Оскільки більшість понять системного аналізу до нас прийшло з-за кордону - дамо основні варіанти їх визначень англійською мовою:
* DFD (Data Flow Diagrams) - діаграми потоків даних. Метод демонструється на функціональній моделі, розглянутої в даному курсовому проекті нижче. По суті, він визначає функціональну страту досліджуваного об'єкта.
* ERD (Entinity-Relationship) - діаграми "сутність-зв'язок". Метод широко використовується при описі структури систем і застосовується головним чином в теорії баз даних. У вітчизняній літературі він в основному описано як метод діаграм ER-типу.
* STD (State Transmition Diagrams) - діаграми переходів станів. Використовуються для опису функціонування даної системи в часі. Аналогом цьому є метод простору станів, з успіхом застосовується при моделюванні систем.

Основним джерелом нашого проекту є книга написана на основі оригінального семестрового курсу лекцій з CASE - технологій, підготовленого і читає автором у вищій комп'ютерної школі при НІВЦ. МДУ ім. Ломоносова протягом чотирьох останніх років, яка призначена насамперед для аналітиків предметної області, керівників програмних проектів, системних аналітиків, проектувальників і розробників інформаційних систем і систем реального часу. Зроблений в книзі акцент на послідовне розгляд найбільш важливих аспектів системного структурного аналізу робить цю книгу особливо корисною для користувачів, які вибирають CASE - системи в якості інструменту для вирішення прикладних задач, а також для студентів, які починають опановувати основи сучасних інформаційних технологій.

Введення в CASE - технології.
За останнє десятиліття сформувався новий напрямок у программотехніке - CASE (Computer - Aided Software/System Engineering). В даний час не існує загальноприйнятого визначення CASE. Зміст цього поняття зазвичай визначається переліком завдань, що вирішуються за допомогою CASE, а також сукупністю застосовуваних методів і засобів. Грубо кажучи, CASE - технологія являє собою сукупність методологій аналізу, проектування, розробки та супроводження складних систем програмного забезпечення (ПЗ), підтриману комплексом взаємозв'язаних засобів автоматизації. CASE - це інструментарій для системних аналітиків, розробників і програмістів, що дозволяє автоматизувати процес проектування і розробки ПЗ.
На цей момент дисципліна CASE оформилася в самостійний наукоємне напрямок у программотехніке, що спричинило за собою утворення потужної САSE - індустрії, що об'єднала сотні фірм і компаній різної орієнтації. Серед них виділяються компанії-розробники засобів аналізу і проектування ПЗ з широкою мережею дистриб'юторських і дилерських фірм; фірми-розробники спеціальних засобів з орієнтацією на вузькі предметні області або на окремі етапи життєвого циклу ПЗ; навчальні фірми, які організовують семінари і курси підготовки спеціалістів; консалтингові фірми, що надають практичну допомогу при використанні CASE-пакетів для розробки конкретних програм; фірми, що спеціалізуються на випуску періодичних журналів і бюлетенів по CASE. Основними покупцями CASE-пакетів за кордоном є військові організації, центри обробки даних і комерційні фірми з розробки ПЗ.
Існує думка, що CASE є найбільш перспективним напрямком у программотехніке. З цим помилково сперечатися, але те, що CASE - найбільш бурхливо і інтенсивно розвивається напрям, є в даний час фактом. Практично жоден серйозний зарубіжний програмний проект не здійснюється без використання CASE - засобів. Відома методологія структурного системного аналізу SАDТ (точніше її підмножина IDEF0) прийнята в якості стандарту на розробку ПО Міністерством оборони США. Більше того, серед менеджерів та керівників комп'ютерних фірм вважається мало не правилом хорошого тону SADT знати основи і при обговоренні будь-яких питань намалювати просту діаграму, яка пояснює суть справи.
CASE дозволяє не тільки створювати "правильні" продукти, але і забезпечити "правильний" процес створення. Основна мета CASE полягає в тому, щоб відділити проектування ПЗ від його кодування та подальших етапів розробки, а також приховати від розробників всі деталі середовища розробки та функціонування. Чим більше діяльності буде винесено у проектування не з кодування, тим краще.
При використанні CASE - технологій міняються етапи життєвого циклу програмної системи, при цьому найбільші зміни стосуються етапів аналізу і проектування. У більшості сучасних CASE - систем застосовуються методології структурного аналізу і проектування, засновані на наочних діаграмні техніках, при цьому для опису моделі проектованої системи використовуються графи, діаграми, таблиці та схеми. Такі методології забезпечують строгий і наочний опис проектованої системи, яке починається з її загального огляду і потім деталізується, набуваючи ієрархічну структуру з усе більшою кількістю рівнів.
CASE - технології успішно застосовуються для побудови практично всіх типів систем ПЗ, проте стійке положення вони займають у наступних областях:
1. Забезпечення розробки ділового та комерційного ПЗ. Широке застосування CASE - технологій обумовлено масовістю цієї прикладної області, в якій CASE застосовується не тільки для розробки ПЗ, а й дві створення моделей систем, що допомагають комерційним структурам вирішувати задачі стратегічного планування, управління фінансами, визначення політики фірм, навчання персоналу і т.д. (цей напрямок одержав свою власну назву - бізнес-аналіз),
2. Розробка системного та керуючого ПО. Активне застосування CASE - технологій пов'язано з великою складністю даної проблематики і з прагненням підвищити ефективність робіт.
CASE - не революція в программотехніке, а результат природного еволюційного розвитку усієї галузі засобів, які називаються раніше інструментальними або технологічними. Однак це й не Confuse Array of Software that does Evrything існує ряд ознак і властивостей, наявність яких дозволяє класифікувати деякий продукт як CASE - засіб. Одним з ключових ознак є підтримка методологій структурного системного аналізу і проектування.
З самого початку CASE - технології розвивалися з метою подолання обмежень при використанні структурних методологій проектування 60-70-х років (складності розуміння, великої трудомісткості і вартості використання, труднощі внесення змін в проектні специфікації і т.д.) за рахунок їх автоматизації та інтеграції підтримуючих засобів. Таким чином, CASE-технології не можуть вважатися самостійними методологіями, вони тільки розвивають структурні методології і роблять ефективнішим їх застосування за рахунок автоматизації.
Крім автоматизації структурних методологій і, як наслідок, можливості застосування сучасних методів системної і програмної інженерії, CASE володіють наступними основними перевагами:
* Покращують якість створюваного програмного забезпечення за рахунок засобів автоматичного контролю (перш за все, контролю проекту),
* Дозволяють за короткий час створювати прототип майбутньої системи, що дозволяє на ранніх етапах оцінити очікуваний результат, · прискорюють процес проектування і розробки;
* Звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;
* Підтримують розвиток та супроводження розробки;
* Підтримують технології повторного використання компонент розробки.

Більшість CASE - засобів засновано на парадигмі методологія/метод/нотація/засіб. Методологія визначає керівні вказівки для оцінки і вибору проекту розробляється ПЗ, кроки роботи та їх послідовність, а також правила розподілу і призначення методів. Метод - це систематична процедура або техніка створення описів компонентів ПЗ (наприклад, проектування потоків і структур даних). Нотації призначені для опису структури системи, елементів даних, етапів обробки і включають графи, діаграми, таблиці, блок-схеми, формальні та природні мови. Засоби - інструментарій для підтримки і посилення методів. Ці інструменти підтримують роботу користувачів при створенні та редагуванні графічного проекту в інтерактивному режимі, вони сприяють організації проекту у вигляді ієрархії рівнів абстракції, виконують перевірки відповідності компонентів.
У додатку 2 містяться концептуальні основи CASE - технології.

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

1. Яка використовується нотація
Перед тим як перейти до розгляду модельованого об'єкта представимо складові елементи мови опису. У його основі лежить методологія структурного системного аналізу Гейне-Сарсона. На верхньому рівні система представлена DFD діаграмою. Отже складовими частинами діаграм є наступні елементи:
Зовнішня сутність. Звичайно це логічні класи предметів або фізичних осіб, що представляють собою джерело або приймач інформації, наприклад фізичні та юридичні особи, банки, біржі, різні фірми і т.д. Зовнішня сутність позначається квадратом, які кидають тінь на діаграму (див. рис. 1.1).
Рис. 1.1. Зображення зовнішньої сутності на діаграмах.
Процес. Логічно процес є певним пристроєм, які приймають вхідні потоки і перетворює їх у вихідні у відповідності зі своєю внутрішньою логікою. Позначається він прямокутником із закругленими кутами, розділеними на три поля (див. рис. 1.2). Кожному процесу дається ім'я, що відображає його функцію. Для ідентифікації процеси в межах однієї діаграми унікально пронумеровані.
Рис. 1.2. Умовне позначення процесу.
Накопичувач даних. Являє собою якийсь пристрій для зберігання інформації, куди її можна помістити і через деякий час вилучити. Позначається він двома паралельними горизонтальними лініями, замкнутими з одного краю - рис. 1.3. Кожен накопичувач даних ідентифікується для посилання літерами "БД" і числом в квадраті з лівого боку.
Рис. 1.3. Умовне позначення накопичувача даних.

Інформаційний канал. Це середовище передачі інформації, куди надходять дані з різних джерел, які не входять до розгляду в дану систему. Умовне позначення каналу містить ідентифікує посилання (букви "ІК" і номер) - див рис. 1.4.
Рис. 1.4. Умовне позначення накопичувача інформаційний каналу.

Інформаційний потік. Логічно інформаційний потік - це деякий підключення, по кото?? ому інформація від джерела передається приймача. Позначення див рис. 1.5.
Рис. 1.5. Умовні позначення інформаційних потоків.

2. Представлення моделі
Функціональна модель діяльності з цінними паперами в комерційному банку, наведено на рис. П.1.1-п.1.9.
На рис. П.1.1 зображений фрагмент діаграми потоків даних з процесом Цінними папери і зовнішніми об'єктами, з якими даний процес взаємодіє (ці взаємодії позначені за допомогою вхідних і вихідних інформаційних потоків). Роль зовнішніх для даного інформаційного процесу об'єктів відіграють зовнішні сутності: ЮЛ (Юридична особа), FL (Фізична особа), Уповноважений депозитарій, Консалтингова фірма, ММВБ, інформаційний (технологічний) канал надходження в банк з різних джерел котирувань цінних паперів а також процеси, що моделюють внутрішню бухгалтерську, зведену бухгалтерську, операційну, кредитну і валютну діяльність банку.
На рис. П.1.2 зображена діаграма потоків даних другого рівня, що деталізує процес Цінні папери містить процеси Аналіз ринку ЦП, Пасивна діяльність з ЦП, Активна діяльність з ЦП, Зв'язок з внутрішньою бухгалтерією (технологічний процес) та Формування поправочних операції.
Процеси 1, 4, 5 рис. П.1.2 є елементарними, і їх логіка описується мініспеціфікаціямі, тобто природною мовою (см далі пункт 3). Діаграма, що деталізує процеси 2 та 3 того ж малюнка, наведені далі на рис. П.1.3 і п.1.4, відповідно. Діаграми, деталізують процеси більш нижнього рівня, наведено на рис. П.1.5-п.1.9.

3. Специфікації процесів діяльності з цінними паперами
Залежно від складності і необхідності, при деталізації процесів верхнього рівня на нижньому, застосовується або їх специфікація діаграмами DFD типу, або опис природними мовними засобами. Як альтернатива останніх можна було б запропонувати й інші методи - наприклад, структурований природну мову або візуальний мова специфікацій; однак ми обмежилися природним, тому що на наш погляд він найкращим чином (більш зрозуміло) описує процеси, що відбуваються.
Процес: Аналіз ринку цінних паперів.
На рис. П.1.2 позначений під номером 1.
Опис:
1) Аналіз процентних ставок за векселями та депозитними сертифікатами інших банків і формування процентних ставок свого банку
2) Формування звітності за проданими та/або погашеним депозитними сертифікатами і виданих і/або сплаченого векселями.
3) Аналіз прибутковості ЦБ різних типів. Прийняття рішень по операціях з ЦП та формування заявок на ресурси.
4) Формування звітності по проведених операціях з ЦП.
Процес: Пасивна діяльність з ЦП
Деталізація процесу (під номером 2 рис. П.1.2) у діаграмі потоків даних рис. П.1.3 і в пункті 3.1.
Процес: Активна діяльність з ЦП
Деталізація процесу (номер 3 на рис. П.1.2) у діаграмі потоків даних рис. П.1.3 та пункті 3.2.
Процес: Зв'язок з внутрішньою бухгалтерією (технологічний процес)
Має номер 4 на рис. П.1.2. Тут здійснюється збір документів з цінних паперів для процесу 10 "Внутрішня бухгалтерська діяльність".
Процес: Формування поправочних операцій
Формування поправочних операцій для процесу 10 рис. П.1.2 "Внутрішня бухгалтерська діяльність" у разі виявлення помилок в операціях з цінними паперами
3.1. Пасивна діяльність з цінними паперами
Процес: Операції з векселями
Деталізація процесу в діаграмі потоків даних рис. П.1.5 та пункті 3.1.1.
Процес: Операції з депозитними сертифікатами
Деталізація процесу в діаграмі потоків даних рис. П.1.6 та пункті 3.1.2.
Процес: Розподіл входів і виходів формування (технологічний)
Опис:
Проводиться розподіл потоків документів з діяльності з векселями та депозитними сертифікатами, а також збір звітності з пасивної діяльності

3.1.1.Операціі з векселями
ПРОЦЕС: Видача
Опис:
1) Оформлення договору за векселями і підшивка екземпляра в папку договорів
2) Оформлення та видача сертифіката ЦП
3) Оформлення витратно-меморіального ордера за цінному бланку та передача його в документи дня за ЦП
4) Формування звітності з ВД за виданим векселем (сума, процентна ставка, дата оплати)
5) Занесення в БД векселів інформації за договором (номер векселя, дата видачі векселя, номер договору, дата укладення договору, процентна ставка, номінал, термін обертання, найменування векселедержателя, банківські реквізити векселедержателя)
6) Запис у журнал операцій
Примітка: Проведення при видачі векселя
До -199, Д 50 (р/р) - сума під вексель
Д - 9959 - облік бланка під вексель
 
ПРОЦЕС: Передача
Опис:
1) Реєстрація цесії в договорі
2) Реєстрація операції в журналі операцій
3) Зміна запису в БД векселів (найменування векселедержателя, банківські реквізити векселедержателя)

ПРОЦЕС: Застава
Опис:
1) В БД векселів реєструється інформація щодо застави (термін застави, найменування кредитора, банківські реквізити кредитора, розмір кредиту)
2) Реєстрація операції в журналі операцій

ПРОЦЕС: Оплата
Опис:
1) Погашення сертифіката ЦП
2) Передача погашеного сертифікату та договору в документи дня за ЦП
3) Оформлення та передача розпорядження до відділу внутрішньобанківських операцій з усіма атрибутами векселі для нарахування відсотків, податків та здійснення проводок
Примітка: Проведення при оплаті векселя
Д 199, К р/р клієнта - номінал векселя
Д 970, К р/р клієнта - відсотки за вирахуванням податку
Д 970, К 904 - податок 15% до бюджету

ПРОЦЕС: Розбір документів і звітність (технологічний процес)
Проводиться розподіл потоків вхідних документів з процесів - операціями з векселями, а також збір та формування звітності за операціями

3.1.2.Операціі з депозитними сертифікатами
ПРОЦЕС: Продаж
Опис:
1) Оформлення договору з ДС і підшивка екземпляра в папку договорів
2) Оформлення та видача сертифіката ЦП
3) Оформлення витратно-меморіального ордера за цінному бланку та передача його в документи дня за ЦП
4) Формування звітності з ПД за виданим ДС (сума, процентна ставка, дата оплати)
5) Занесення в БД Де інформації за договором (номер ДС, дата видачі ДС, номер договору, дата укладення договору, процентна ставка, номінал, термін обігу, найменування власника, банківські реквізити держателя)
6) Запис у журнал операцій
Примітка: Проведення при видачі ДС
Д 9959 - облік бланка під ДС
До 199 Д р/р - сума під ДС

ПРОЦЕС: Застава
Опис:
1) В БД Де реєструється інформація щодо застави (термін застави, найменування кредитора, банківські реквізити кредитора, розмір кредиту)
2) Реєстрація операції в журналі операцій

ПРОЦЕС: Передача
Опис:
1) Реєстрація індосаменту в доге злодієві
2) Реєстрація операції в журналі операцій
3) Зміна запису в БД Де (найменування держателя банківські реквізити держателя)

ПРОЦЕС: Погашення
Опис:
1) Погашення сертифіката ЦП
2) Передача погашеного сертифікату та договору в документи дня за ЦП
3) Оформлення та передача розпорядження до відділу внутрішньобанківських операцій з усіма атрибутами ДС для нарахування відсотків, податків та здійснення проводок
Примітка: Проведення при погашенні ДС
ДТ-199, КТ - р/р клієнта - номінал ДС
ДТ-970, КТ-р/р клієнта - відсотки за вирахуванням податку
ДТ-970, КТ -904 - податок 15% до бюджету

3.2. Активна діяльність з цінними паперами
Процес представлений на рис. П.1.4.
ПРОЦЕС: Операції з ДКО
Деталізація процесу в діаграмі потоків даних рис. П.1.7 та пункті 3.2.1

ПРОЦЕС: Операції з КВ
Деталізація процесу в діаграмі потоків даних п.1.8 та пункті 3.2.2.

ПРОЦЕС: Операції з ВО
Деталізація процесу в діаграмі потоків даних п.1.9 та пункті 3.2.3.

3.2.1. Операції з ДКО

ПРОЦЕС: Купівля
Опис:
Для кожного випуску ГКО по кожній операції купівлі вноситься запис журнал особового обліку
1) За номером державної реєстрації вибирається поточна сторінка відповідного журналу обліку особового
2) Заповнюється чергова рядок сторінки
(х, 3) = ціна операції в% до номіналу
(х, 2) = кількість штук
(х, 4) = (х, 2) * (х, 3)

ПРОЦЕС: Продаж
Опис:
Для кожного випуску ГКО по кожній операції продажу вноситься запис у журнал обліку особового
1) За номером державної реєстрації вибирається поточна сторінка відповідного журналу обліку особового
2) Заповнюється чергова рядок сторінки
(x, 5) = кількість штук
(x, б) = ціна операції в% до номіналу
(x, 7) = (х, 5) * (x, 6)

ПРОЦЕС: Погашення
Опис:
Для кожного випуску ГКО по кожній операції погашення вноситься запис у журнал обліку особового
1) За номером державної реєстрації вибирається поточна сторінка відповідного журналу обліку особового
2) Заповнюється чергова рядок сторінки
(х, 5) = кількість штук
(х, 6) = номінал
(х, 7) = (х, 5) * (х, 6)

ПРОЦЕС: Вибір операції і звіт за результатами
Опис:
Для кожного випуску ГКО формується сторінка журнал особового обліку
1) До виконання операції здійснюється:
Вибрати видання за номером державної реєстрації
1 символ-= 2 - вид ЦП (боргове зобов'язання)
2 символи = SU - можуть бути відсутні
1сімвол = 1/2/3 - тип ЦП (1-для тримісячних, 2-для шестимісячних, 3-для річних)
3 символи = порядковий номер випуску даного типу
4 символу = RMFS
Заповнення 1-го рядка сторінки журналу
(1,1) = дата проведення операцій
Заповнення 2-го рядка - залишок на початок дня (береться з попередньої сторінки)
(2,1) =% залишок на початок дня%
(2,2) = кількість ДКО даного випуску в портфелі
(2,3) = ціна попереднього робочого дня у% до номіналу
(2,4) = (2,2) * (2,3)
2) Після виконання операцій в кінці дня здійснюється:
Заповнення рядка РАЗОМ (валові результати з купівлі та продажу ДКО за день) по колонках 2,4,5,7
Заповнення рядка ЗАЛИШОК НА КІНЕЦЬ ДНЯ
ЗАЛИШОК (2) - РАЗОМ (2)-РАЗОМ (5)
ОСТАТСК (3) = середня біржова ціна по даному випуску
ЗАЛИШОК (4) = ЗАЛИШОК (2) * ЗАЛИШОК (3)
Обчислення показників
ЗМІНА ПОРТФЕЛЬ = ЗАЛИШОК НА КІНЕЦЬ (4)-ЗАЛИШОК НА ПОЧАТОК (4)
САЛЬДО РОЗРАХУНКІВ = РАЗОМ (7)-РАЗОМ (4)
Сума переоцінки = ЗМІНА ПОРТФЕЛЬ + САЛЬДО РОЗРАХУНКІВ
КОМІСІЯ ММВБ = РАЗОМ (4) * 0,001
ПОДАТОК = РАЗОМ (4) * 0,001
КОМІСІЯ БРОКЕРА = РАЗОМ (4) * (відсоток комісії)
ПРОЦЕС: Переоцінка
Опис:
За всіх випусків ГКО заповнюється чергова сторінка журналу обертів з операцій на основі журналів особового обліку
1) По кожному випуску ГКО заповнюється один рядок таблиці
(*, 1) = номер державної реєстрації
(*, 2) = ЗМІНА ПОРТФЕЛЬ
(*, 3) = САЛЬДО РОЗРАХУНКІВ
(*, 4) = сума переоцінки
(*, 5) = ЗАЛИШОК НА КІНЕЦЬ (4)
(*, 6) = (*, 4) + [старе значення (*, 6), яке скидається на початку кожного місяця]
(*, 7) = КОМІСІЯ ММВБ
(*, 8) = ПОДАТОК
2) підводиться загальний підсумок по колонках 2-8 (рядок РАЗОМ з перевіркою РАЗОМ (4) = РАЗОМ (2) + РАЗОМ (3)
Примітка: проведення за підсумками переоцінки
Якщо РАЗОМ (2)> 0 то Д 194
Якщо РАЗОМ (2)
Якщо РАЗОМ (3)> 0 то Д 904
Якщо РАЗОМ (3)
Якщо РАЗОМ (4)> 0 то До 960
Якщо РАЗОМ (4)
РАЗОМ (7) Д 970, К 904
РАЗОМ (8) Д 950, К 904

3.2.2. Операції з КВ
Процес представлений на рис. П.1.8. Опишемо процеси нижнього рівня.
ПРОЦЕС: Купівля
Опис:
Реєстрація КВ в журналі обліку КВ
- Реєстраційний номер випуску (7 символів)
1-й (літера) - серія = галузь народного господарства
2-З-й - день випуску серії
4-5-й - місяць випуску серії
6-7-й - порядковий номер випуску
- Кількість ЦП
- Номінал = 1. млн. руб.
- Місце зберігання
- Номер субрахунка депо
- Статус субрахунка
- Дата початку погашення
- Дата закінчення погашення
-дата пред'явлення для обміну на податкові звільнення
- Обмеження щодо кількості індосаментів
Примітка: Проведення при будут КВ
Д 194, К 904

ПРОЦЕС: Продаж
Внесення змін до журналу обліку КВ
Примітка: Проведення при Продажу КВ
Д 904, К 194

ПРОЦЕС: Погашення кредиторської заборгованості
Внесення змін до журналу обліку КВ
Примітка: Проведення при погашенні кредиторської заборгованості
Д 904, К 194

ПРОЦЕС: Застава
Примітка: На момент побудови моделі дана операція не проводилася

ПРОЦЕС: Погашення
Внесення змін до журналу обліку КВ
Примітка: Проведення при погашенні КО (за номіналом
Д 904, К 194

ПРОЦЕС: Обмін на податкові звільнення
Примітка: На момент побудови моделі дана операція не проводилася

ПРОЦЕС: Вибір операції і звіт за результатом (технологічний)
Опис:
1) Проводиться вибір операції з КВ і формування заявки на проведення операції
2) Здійснюється формування звітності з проведеної операції з КВ

3.2.3. Операції з ВО

ПРОЦЕС: Купівля
Опис:
Занесення інформації до журналу обліку ВО (номер траншу, кількість ЦП, номінал, серія, з номера ...., по номер ...., термін обігу, дата погашення)
Примітка: Проведення при будут ВО (в рублевому еквіваленті)
Д 194, К 904

ПРОЦЕС: Продаж
Коригування журналу обліку ВО
Примітка: Проведення при Продажу ВО (в рублевому еквіваленті)
Д 904, К 194

ПРОЦЕС: Мена
Примітка: На момент побудови моделі дана операція не проводилася

ПРОЦЕС: Застава
Примітка: На момент побудови моделі дана операція не проводилася

ПРОЦЕС: Договір РЕПО
Примітка: У банку дана операція замінялася парою операцій КУПІВЛЯ-ПРОДАЖ

ПРОЦЕС: Вибір операції і звіт за результатом (технологічний)
Опис:
1) Проводиться вибір операції з ВО і формування заявки на проведення операції з ВО
2) Здійснюється формування звітності з проведеної операції з ВО

Додаток 2. Концептуальні засади CASE - технології

Еволюція CASE - засобів
З самого початку CASE - технології розвивалися за рахунок автоматизації та інтеграції підтримують коштів. Таким чином CASE - технології не можуть вважатися самостійними методологіями, вони тільки роблять більш ефективними шляхи їх застосування. CASE - не революція в программотехніке сучасні CASE -
кошти є природним продовженням еволюції всієї галузі засобів розробки ПЗ. Традиційно наробив шість періодів, якісно відрізняються застосовуваної технікою і методами розробки ПЗ, які характеризуються використанням як інструментальних наступних засобів;
* Асемблері, дампів пам'яті, аналізаторів;
* Компіляторів, і інтерпретаторів, трассіровщіков;
* Символічних відладчиком, пакетів програм;
* Системи аналізу та управління вихідними текстами;
* CASE-засобів аналізу вимог, проектування специфікацій і структури, редагування інтерфейсів (перша генерація CASE-I);
* CASE - засобів генерації вихідних текстів і реалізації інтегрованого оточення підтримки повного життєвого циклу (ЖЦ) розробки ПО (друга генерація CASE-II).
CASE-I є першою технологією, що адресована безпосередньо системним аналітикам і проектувальникам, і включає засоби для підтримки графічних моделей, проектування специфікацій, екранних редакторів та словників даних. Вона не призначена для підтримки повного Ж Ц і концентрує увагу на функціональних специфікаціях і початкових кроків проекту - системний аналіз, визначення вимог, системному проектуванні, логічному проектуванні БД.
CASE-II відрізняється значно більш розвиненими можливостями, поліпшеними характеристиками і вичерпним підходом до повного ЖЦ. У ній в першу чергу використовуються засоби підтримки автоматичної кодогенераціі, а також забезпечується повна функціональна підтримка породження графічних системних вимог і специфікацій проектування, контролю, аналізу та скріплення системної інформації, а також інформації з управління проектуванням; побудови прототипів і моделей системи; тестування, верифікації і аналізу згенерованих програм; створення документів по проекту; контролю на відповідність стандартам по всіх етапах ЖЦ. СА5Е-Н може включати понад 100 функціональних компонентів, що підтримують всі етапи ЖЦ., При цьому користувачам надається можливість вибору необхідних засобів та їх інтеграції а потрібному складі.

CASE - модель життєвого циклу ПО

CASE - технології пропонують новий, заснований на автоматизації підхід до концепції ЖЦ, ПЗ. При використанні CASE змінюються всі фази ЖЦ, при цьому найбільшарілі зміни стосуються фаз аналізу і проектування. На рис. 1.1а наводиться найпростіша модель ЖЦ, і відповідна CASE - модель (ріс.1.1б), в якій фаза прототипирування замінює традиційну фазу системного аналізу. Необхідно відзначити, що найбільш автоматизуються фазами є фази контролю проекту і кодогенераціі хоча всі інші фази також підтримуються CASE - засобами).
У таблиці 1.1 наведені оцінки трудовитрат за фазами ЖЦ. Перший рядок таблиці відповідає традиційній розробці, другий - розробці з використанням структурних проектування методологій, третє - розробці з використанням CASE - технологій. У таблицю 1.2 зведені основні зміни в ЖЦ при використанні CASE - технологій в порівнянні з традиційною розробкою.
Прототипування
Таблиця 1.1
Аналіз
Проектування
Кодування
Тестування
20%
15%
20%
45%
30%
30%
15%
25%
40%
40%
5%
15% Таблиця 1.2
NN
Традиційна розробка
 CASE
1
Основні зусилля - на кодування і тестування
Основні зусилля - на аналіз і проектування
2
"Паперові" специфікації
Швидке Ітеративний Прототипування
3
Ручне кодування
Автоматична кодогенерація
4
Ручне документування
Автоматична генерація документації
5
Тестування кодів
Автоматичний контроль проекту
6
Супровід кодів
Супровід специфікацій проектування
Склад, структура і функціональні особливості CASE-засобів
CASE - засоби служать інструментарієм для підтримки і посилення методів структурного аналізу і проектування. Ці інструменти підтримують роботу користувачів при створенні та редагуванні графічного проекту в інтерактивному режимі, вони сприяють організації проекту у вигляді ієрархії рівнів абстракції, виконують перевірки відповідності компонентів. Фактично CASE-засоби являють собою новий тип графічно-орієнтованих інструментів, висхідних до системи підтримки ЖЦ ПЗ. Зазвичай до них відносять будь-яке програмне засіб, що забезпечує автоматичну допомогу при розробці програмного забезпечення, його супроводі або діяльності з управління проектом, і проявляє наступні додаткові риси:
* Потужна графіка для опису і документування систем ПЗ, а також для поліпшення інтерфейсу з користувачем, що розвиває творчі можливості фахівців і не відволікали їх від процесу проектування на вирішення другорядних питань;
* Інтеграція, що забезпечує легкість передачі даних між засобами і що дозволяє управляти всім процесом проектування і розробки ПЗ безпосередньо через процес планування проекту;
* Використання комп'ютерного сховища (сховища) для всієї інформації про проект, яка може поділятися між розробниками і виконавцями як основа для автоматичного продукування ПЗ і повторного його використання в майбутніх системах.

Крім перерахованих основних принципів графічної орієнтації, інтеграції та мовні пакети