Тема: Начальное планирование проекта АИС
Цели:
- Сформулировать цели проекта с использованием SMART характеристик;
- Определить действия, которые необходимо выполнить для разработки АИС;
- Определить ресурсы, требуемые для реализации проекта;
- Оценить длительности каждого действия и всего проекта в целом;
- Сконструировать и интерпретировать диаграмму Ганта и сетевую модель, соответствующие проекту по разработке АИС.
Требования:
- Формулировка основных целей проекта.
- Фиксирование основных характеристик проекта (Название, автор и т.д.).
- Определение графика работы команды проекта и отклонения от стандартного календаря (если есть необходимость).
- Определение списка действий, необходимых для разработки АИС (они могут быть сгруппированы по процессам и по этапам).
- Фиксирование даты начала и завершения для каждого действия, определние длительности каждого действия.
- Построение диаграммы Gantt.
- Определние и описание необходимых ресурсов для выполнения проекта (людские, материальные, технические, денежные).
- Распределение ресурсов по действиям.
- Подсчет стоимости проекта (бюджет проекта).
- Определение взаимосвязей между действиями. Построение сетевой модели (PERT-диаграмма).
- Управление использемых ресурсов (мониторинг правильного распределения ресурсов для каждого действия проекта).
- Обоснование использования MS PROJECT-а для разработки плана проекта.
Замечание: Календарный план проекта можно реализовать от руки или используя графические или текстовые редакторы типа MS WORD, или можно использовать MS PROJECT, который является CASE средством, используемым в планировании проектов.
Основные понятия, которые необходимо знать для выполнения данной работы:
Pentru a îndeplini acţiunile/transformările necesare asupra sistemului informatic în decursul ciclului său de viaţă, organizaţia creează şi controlează proiecte [6]. Proiectele au anumite limite, termene şi scop.
Scopul proiectului este legat cu scopul sistemului informatic în întregime, sau cu părţile sale componente.
Orice sistem se poate diviza în sisteme mai mici şi în acelaşi timp poate fi parte a altui sistem informatic de proporţii mai mari.
SMART – это аббривиатура, используемая для правильной формулировки целей. Цели могут быть общими либо специфическими.
Aceste caracteristici sunt următoarele:
S – specific;
M – măsurabil;
A – (de) atins/abordabil;
R – relevant;
T – încadrat în timp.
Comisia Europeană, în Manualul privind Managementul Ciclului Proiectului, utilizează criteriile SMART doar în ceea ce priveşte formularea indicatorilor de măsurare a atingerii obiectivelor propuse. Cum indicatorii sunt legaţi de obiective, însă trebuie să reflecte o imagine reală a gradului de atingere a acestora, este normal deci să apară diferenţe de concept.
Specific – înseamnă că un obiectiv indică exact ceea ce se doreşte a se obţine. Un obiectiv specific este foarte clar exprimat, nu lasă loc de îndoieli. Un obiectiv specific diferă în primul rând de unul general. El vizează rezultate concrete, iar nu rezultate în general.
Măsurabil – înseamnă că un obiectiv poate fi cuantificat, fie cantitativ, fie calitativ. Un obiectiv măsurabil este cel care permite stabilirea cu exactitate a faptului că a fost atins ori nu sau în ce măsură a fost atins. De asemenea, un obiectiv măsurabil permite monitorizarea progresului atingerii lui.
Exemplu de obiectiv general: "organizarea unui training pentru participanţii la proiectul X". Exemplu de obiectiv specific: "organizarea unui training pe tema scrierii documentaţiei tehnice pentru cele două persoane responsabile de documentarea (scrierea documentaţiei tehnice) implicate în proiectul X".
Se poate vedea, în exemplul de mai sus, că, prin compararea situaţiei de la un moment dat cu obiectivul, se poate măsura dacă a fost atins ori nu sau în ce măsură a fost atins (Ex: 50%, daca la training a participat doar o persoană).
Abordabil/de Atins/reAlizabil – înseamnă că un obiectiv poate fi într-adevăr atins. În acest sens, trebuie luate în considerare mai multe aspecte:
- prin definirea obiectivului nu se propune realizarea a ceva imposibil de atins în condiţiile date. De exemplu: trainingul va fi ineficient dacă va dura doar 45 minute;
- obiectivul în cauză, poate fi atins în condiţiile proiectului, de către organizaţia sau persoana care este responsabilă de realizarea lui. În acest sens, trebuie ţinut cont de resursele existente, capacitatea organizaţiei, timpul disponibil necesar.
Relevant – înseamnă că realizarea obiectivului contribuie la impactul vizat de proiect. Realizarea unui obiectiv trebuie să contribuie în mod nemijlocit la atingerea unui obiectiv mai mare, mai general. În acest sens, el trebuie să vizeze un anumit impact. De exemplu instruirea celor 2 persoane responsabile de documentarea proiectelor soft va avea impact asupra numărului mai mare de documentare a proiectelor realizate de organizaţie. Dacă impactul obiectivului ar fi ca organizaţia să crească numărul de proiecte care ar fi documentate de alte persoane, care activează în alte organizaţii, atunci obiectivul "organizarea unui training pe tema scrierii documentaţiei tehnice pentru cele două persoane responsabile de documentarea (scrierea documentaţiei tehnice) implicate în proiectul X" nu ar fi relevant, deoarece cei doi angajaţi nu ar trebui să mai scrie documentaţie tehnică.
Încadrat în Timp – înseamnă că obiectivul conţine şi data până la care este prevăzut a se realiza. Exemplu: "organizarea în perioada 7-10 octombrie 2013 a unui training pe tema scrierii documentaţiei tehnice pentru cele două persoane responsabile de documentarea (scrierea documentaţiei tehnice) implicate în proiectul X" – reprezintă un obiectiv încadrat în timp.
Ciclul de viaţă al unui sistem informatic constă dintr-un şir de etape la care sistemul software este planificat, proiectat, creat, implementat, exploatat, menţinut şi anulat. Ciclul de viaţă este strâns legat de cerinţele formulate faţă de SI.
La îndeplinirea proceselor ciclului de viaţă al SI pot fi evidenţiate următoarele roluri de bază:
- managerul proiectului;
- reprezentantul beneficiarului;
- consultantul juridic;
- analistul proceselor de activitate (business proces);
- managerul elaborării SI;
- proiectantul proceselor de activitate;
- analistul de sistem;
- arhitectul sistemului;
- proiectantul sistemului;
- proiectantul interfeţei pentru utilizator;
- programatorul;
- integratorul;
- persoana responsabilă de testare (inginer al calităţii);
- elaboratorul testelor;
- scriitorul documentaţiei tehnice;
- managerul implementării produsului software;
- administratorul de sistem;
- administratorul bazelor de date;
- managerul exploatării;
- utilizatorul produsului software;
- managerul mentenanţei produsului software;
- specialistul dirijării configuraţiei;
- analistul serviciului de mentenanţă;
- persoana de testare a serviciului de mentenanţă.
Observaţie: La realizarea proiectelor concrete, se admite completarea componenţei rolurilor, predeterminate de prezenta reglementare tehnică, precum şi îndeplinirea a cîtorva roluri de către un singur executant.
Примеры артефактов для 4-ой лабораторной работы:
1. Пример описания действий среднего проекта (при использовании каскадной модели жизненного цикла разработки АИС)
Основные цели: __________________________
Специфические цели: __________________________
Результаты, которые необходимо достигнуть: ___________________________
START
1. Формулировка требований и разработка стратегии: 1-2 недели.
2. Анализ: 3 месяца.
· Интервьюирование экспертов предприятия – 1-2 недели (интервьюируется минимум 2 эксперта);
· Исследование предметной области, для которой разрабатывается АИС – 2 недели;
· Анализ информационных систем и создание организационной структуры предприятия – 2 предприятия;
· Исследование существующих АИС – 1 неделя;
· Создание словаря терминов – 1 неделя;
· Создание документации для работы над следующими этапами – 1-2 недели;
Ø Создание технического задания – 2-3 дня;
Ø Разработка календарного плана – 1-2 дня;
Ø Определение необходимых технических ресурсов – 2-5 дней;
Ø Разработка и заключение контрактов на проектирование, разработку и внедрение АИС – 2-5 дней.
3. Проектирование – 4 месяцев.
· Разработка моделей данных (архитектура БД, ERD) 3 недели;
· Разработка архитектуры программного обеспечения (описание компонентов и связей между ними) 2 недели;
· Разработка моделей интерфейсов (структура и форма экранов для ввода данных и для выходящей информации и отчетов) 3 недели;
· Разработка моделей процессов/функций системы (DFD и описание алгоритмов функционирования) 2 недели;
· Описание технических требований к серверам и рабочим места и программному обеспечению для них (для тестировщиков и пользователей) – 1 неделя.