Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

• визначається необхідність розподілу даних;

• здійснюється аналіз використання даних;

• здійснюється фізичне проектування бази даних;

• визначаються вимоги до апаратних ресурсів;

• визначаються способи збільшення продуктивності;

• завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім погодженим вимогам.

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

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

Наведена схема розробки ІС не є абсолютною. Можливі різні варіанти, що залежать, наприклад, від початкових умов, у яких ведеться розробка: розробляється зовсім нова система; уже було проведене обстеження підприємства й існує модель його діяльності; на підприємстві вже існує деяка ІС, що може бути використана як початковий прототип або повинна бути інтегрована з розроблювальною.

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

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

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

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

< 1000 функціональних елементів	одна людина
1000-4000 функціональних елементів	одна команда розроблювачів
> 4000 функціональних елементів	4000 функціональних елементів на одну команду розроблювачів

Підсумовуючи викладене, перелічимо основні принципи методології RAD:

• розробка додатків ітераціями;

• необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

• обов'язкове залучення користувачів у процес розробки ІС;

• необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

• застосування засобів керування конфігурацією, що полегшують внесення змін у проект і супровід готової системи;

• необхідне використання генераторів коду;

• використання прототипування, що дозволяє повніше з'ясувати й задовольнити потреби кінцевого користувача;

• тестування й розвиток проекту, здійснювані одночасно з розробкою;

• ведення розробки нечисленною добре керованою командою професіоналів;

• грамотне керівництво розробкою системи, чітке планування й контроль виконання робіт.

Завдання ІІ. Бізнес-процеси складського підрозділу

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

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

Рекомендовані дані: класифікатор матеріалів, матеріал, матеріально-відповідальні особи, підрозділи, прихід-витрата матеріалів.

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

1. Вендров А.М. CASE-технологии. Современные средства и средства проектироания информационных систем. – М.: ФиС, 1998 . – 216 с.

2. Дубейковский В. И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM. – М.: Диалог-МИФИ, 2007. – 384 с.

3. Маклаков С.В. BPwin и ERwin. CASE - средства разработки информационных систем. – М.: Диалог-МИФИ, 2007. – 256 с.

4. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: Диалог-МИФИ, 2005. – 432 с.

5. Свитинбенк Петер, Чессел Менди и др. Шаблоны: управляемая моделями разработка в среде IBM Rational Software Architect. – М.: Академия. 2006. – 215 с.

6. Чаадаев В.К. Бизнес-процессы в компаниях связи. – М.Диалог, 2006. – 176 с.

Размещено на Allbest.ru

Характеристики

Список файлов ответов (шпаргалок)