ження;
Існує чотири варіанти стратегії автоматизації:
o хаотична;
o по ділянках;
o за напрямами;
o повна;
Хаотична автоматизація складається з набору автоматизованих ділянок, не пов'язаних один з одним. Така автоматизація визначається оперативними завданнями і зазвичай не відображається в стратегічних планах компанії.
Автоматизація по ділянках являє собою процес автоматизації окремих функціональних ділянок, наприклад, відділ бухгалтерії, комерційний відділ і т.д.
Автоматизація за напрямами. Відрізняється від автоматизації по ділянках тим, що припускає участь всіх функціональних підрозділів, діяльність яких пов'язана з напрямком автоматизації.
Повна автоматизація передбачає автоматизацію всіх бізнес-процесів компанії.
Компанія ТО «³п Ай Ті Маркет В»має невеликий розмір і досить високі темпи розвитку. Поетом найбільш доцільною стратегією прийнято використовувати другу модель автоматизації: автоматизації по ділянках (відділ тестування). З можливістю розширити систему до автоматизації за напрямом (повна розробка).
Розробка і впровадження автоматизованої системи документообігу відділу тестування в компанії ТО «³п Ай Ті МаркетВ» здійснюватиметься таким чином:
1. Передпроектний аудит.
2. Компанія-розробник разом із Замовником проводять передпроектне дослідження автоматизируемого ділянки. Визначаються функціональні вимоги. p> 3. Вибір оптимального рішення.
На другому етапі Замовник з Розробником вибирають максимально ефективний варіант реалізації системи автоматизації.
4. Розробка технічного завдання.
Складання максимально докладного технічного завдання. Формулювання та документування всіх необхідних завдань. Узгодження з Замовником і Розробником тексту технічного завдання, щоб уникнути двоякого розуміння тез.
5. Кодування. p> Написання коду продукту відповідно з текстом технічного завдання. Налагодження програми;
6. Тестування. p> Перевірка працездатності програми на платформі Замовника. Всі виявлені помилки відправляються Розробнику на доопрацювання.
7. Здавання проекту.
Демонстрація Замовнику можливостей, описаних у технічному завданні.
3.3 Вибір та обгрунтування способу придбання ІС для автоматизації комплексу завдань
Існують різні варіанти розробки та впровадження автоматизованих систем документообігу:
В· Розробка системи власними ресурсами.
В· Використання стороннього розробника.
В· Використання прототипів.
В· Придбання готової системи.
Розробка системи власними ресурсами. Дозволяє масштабувати і змінювати систему в будь-який момент часу. Однак вимагає значних витрат на розробку і підтримку. Для маленької компанії це може бути невигідно з економічної точки зору.
Використання стороннього розробника. Дозволяє створити гнучку систему управління документообігом. Однак витрата на розробку і підтримку сильно перевищує використання прототипів або готової системи.
Використання прототипів - досить гнучкий варіант. Але в даний час системи управління тестуванням не сильно поширені. А використання прототипів сторонньої тематики може обернутися нерозумінням фахівців термінології системи.
Придбання готової системи дозволяє заощадити кошти на розробку. До того ж готові засоби управління тестуванням перевірені часом. Вони передбачають ряд функціоналу, що здається на перший погляд неефективним, але набув, важливість у процесі експлуатації.
З запропонованих варіантів прийнято розробку власного АРМ фахівця з тестуванню, зважаючи економічної і технічної доцільності використання продукту.
4. Обгрунтування проектних рішень
В
4.1 Обгрунтування проектних рішень з інформаційному забезпеченню
АРМ фахівця з тестування використовується як основний засіб взаємодії відділу тестування з відділом програмування і з відділом інформаційних технологій. Основа АРМ фахівця з тестування - список дефектів і тестових сценаріїв. Ці робочі елементи повинні бути класифіковані. p> Структура списку дефектів повинна забезпечувати швидкий пошук. Для цього доцільно при створенні структури враховувати основні принципи розробки програмного забезпечення. Пропонується вивчити всі найпопулярніші класифікатори. І поєднати їх з власними характеристиками діяльності відділу.
Пропонується відображати в списку дефектів наступні атрибути:
1. ID робочого елемента;
2. Тема;
3. Кому призначений дефект;
4. Статус;
5. Дата створення;
Каталог тестових сценаріїв повинен бути зручний для сприйняття користувачем. Для цього його слід структурувати. Пропонується побудувати ієрархічну модель тестів. У корені дерева буде знаходитися проект. Далі йде розбиття за типами тестування. У кожного типу підкаталоги об'єктів тестува...
