47
приложения, и предоставляет пользователю выбор из имеющихся
значений;
• календари, этот компонент очень эффективен в применении за счет
малого места, занимаемого им на форме. При этом он позволяют вводить
дату из выпадающего календаря (по виду напоминают выпадающие
списки) и обеспечивает безошибочный с точки зрения синтаксиса ввод
дат;
• таблицы, позволяют представлять информацию в удобном,
структурированном виде.
Разработанные экранные формы:
• Экра
нная форма спи
ска справочника «Сотру
дники».
• Экранная фор
ма «Результаты аттестации сотрудников».
• Экранная фор
ма «Приказ об аттестации сотрудника».
• Экра
нная форма спи
ска справочника «Анк
еты».
• Экра
нная форма элем
ента справочника «Анк
еты».
• Экра
нная форма спи
ска справочника «Штат
ное расписание».
• Экранная фор
ма списка справо
чника «Должности».
• Экранная фор
ма справо
чника «Статьи затрат».
• Экра
нная форма справочника «Торг
овые точки».
1.4.2. Обоснование проек
тных решений п
о программному обеспе
чению
Одним и
з важных требо
ваний, предъявляемых к проектированию
информа
ционных систем, эксплуат
ируемых совместно н
а технологической ба
зе
весьма ограни
ченных возможностей, явля
ется большая и
х однородность,
позвол
яющая обеспечить совмест
имость, мобильность, перенос
имость.
Выбор сист
емы управления ба
зой данных (СУ
БД) представляет соб
ой
сложную многопарам
етрическую задачу и является одн
им из важ
ных этапов пр
и
разработке прило
жений баз дан
ных. Выбранный програ
ммный продукт дол
жен
удовлетворять ка
к текущим, та
к и буду
щим потребностям предпр
иятия, при эт
ом
48
следует учиты
вать финансовые затр
аты на приобр
етение необходимого
оборуд
ования, самой сист
емы, разработку необхо
димого программного
обеспе
чения на е
е основе, а также обуч
ение персонала. Кро
ме того, необх
одимо
убедиться, чт
о новая СУ
БД способна прин
ести предприятию реал
ьные выгоды.
Наиб
олее простой под
ход при выб
оре СУБД осно
ван на оце
нке того, в
какой ме
ре существующие сист
емы удовлетворяют осно
вным требованиям
создав
аемого проекта информа
ционной системы. Бол
ее сложным и
дорогостоящим вариа
нтом является созд
ание испытательного прое
кта на осн
ове
нескольких СУ
БД и послед
ующий выбор наиб
олее подходящего и
з кандидатов.
Н
о и в этом слу
чае необходимо ограни
чивать круг возмо
жных систем, опир
аясь
на нек
ие критерии отб
ора. В дан
ном случае мож
но выделить неско
лько групп
крите
риев:
• Моделирование дан
ных
• Особенности архите
ктуры и функцио
нальные возможности
• Конт
роль работы сист
емы
• Особенности разра
ботки приложений
• Производи
тельность
• Надежность
• Требо
вания к рабо
чей среде
• Смеша
нные критерии
Осно
вным принципом выб
ора СУБД след
ует считать опреде
ление
программного прод
укта, в наибо
льшей мере соответс
твующего предъявляемым
требов
аниям. Эту зад
ачу решить н
е очень про
сто. Во-пер
вых, к СУ
БД
предъявляется боль
шое число требо
ваний, которые с течением врем
ени
изменяются, в
о-вторых, СУ
БД имеют боль
шое число парам
етров, что затру
дняет
их сравн
ение. Кроме то
го, информация о СУБД час
то носит рекла
мный характер,
н
е позволяющий сдел
ать правильное сужд
ение.
Процедуру выб
ора СУБД след
ует проводить в три эта
па:
• На качест
венном уровне оцен
ить предлагаемые програ
ммные продукты
49
н
а предмет пригод
ности;
• Оценка технич
еских характеристик отобр
анных систем;
• Оце
нка производительности програ
ммных продуктов.
К числу осно
вных показателей пригод
ности программных проду
ктов
относятся:
• ви
д программного прод
укта;
• категории пользов
ателей (профессиональные програ
ммисты,
администраторы Б
Д, квалифицированные пользо
ватели, разрабатывающие
прило
жения, конечные пользо
ватели, различные комби
нации перечисленных
катег
орий);
• удобство и простота использ
ования (понятные проце
дуры установки
програ
ммных продуктов, удоб
ный и унифицир
ованный интерфейс конеч
ного
пользователя, прос
тота выполнения обыч
ных операций: созд
ания БД, навиг
ации,
модификации, подго
товки данных, выпол
нения запросов и отчетов и ряда дру
гих;
наличие интеллек
туальных подсистем подск
азок, помощи в процессе раб
оты и
обуч
ения, включая прим
еры);
• модель предста
вления данных. Наиб
олее распространенной явля
ется
реляционная мод
ель данных. Перспек
тивными являются мод
ели с объек
тной
ориентацией, поско
льку они обла
дают большими возможн
остями отражения
семан
тики предметной обла
сти;
• качество сред
ств разработки. Пр
и оценке каче
ства средств разра
ботки
учитывается следу
ющее: возможности созд
ания пользовательских интерф
ейсов,
мощность язы
ка создания прог
рамм, автоматизация разра
ботки различных
объе
ктов: экранных фо
рм, отчетов, запр
осов. Предпочтение отда
ется системам,
имею
щим полнофункциональные генер
аторы и обеспеч
ивающим удобство
раб
оты пользователя;
• каче
ство средств защ
иты и конт
роля корректности ба
зы данных. Дос
туп к
функ
циям защиты дол
жен предусматриваться н
а уровне сред
ств разработки
прог
рамм и н
а уровне пользо
вателя. К важне
йшим функциям конт
роля
50
корректности относ
ятся: обеспечение уникал
ьности записей Б
Д по перви
чному
ключу, автомат
ический контроль целост
ности связей меж
ду таблицами в
о время
выпол
нения операций обнов
ления, вставки и удаления запи
сей, проверка
коррек
тности значений в БД;
• каче
ство коммуникационных сред
ств. При оце
нке качества
коммуник
ационных средств обра
щают внимание н
а следующие свой
ства
программных проду
ктов:
• поддержку сете
вых протоколов,
• подде
ржку стандартных интерф
ейсов,
• наличие сред
ств групповой раб
оты с информ
ацией,
• способ
ность использовать и модифицировать базы данных других
форм
атов без импорти
рования или преобра
зования;
• фирма – разраб
отчик. Солидность фир
мы-разработчика пак
ета, как
прав
ило, дает следу
ющие преимущества:
• высо
кое качество прод
укта,
• наличие докуме
нтации и методи
ческих материалов
• нали
чие «горячей лин
ии» для консул
ьтаций по возник
ающим проблемам.
Пр
и выборе прод
укта следует обра
тить внимание н
а дату ег
о появления. В
качестве показа
телей «благополучия» мож
но использовать: твер
дое финансовое
полож
ение, перспективная дина
мика развития аппар
атно-программных сред
ств,
годовой обо
рот, численность сост
ава, объем про
даж и т.д. - стоим
ость. На
стоим
ость программных проду
ктов в осно
вном влияют ви
д программного
прод
укта и фир
ма – разработчик. Стоим
ость полнофункциональных СУ
БД
обычно колеб
лется в пред
елах $ 500 - $ 1000. Общая стоим
ость включает в себя
стоим
ость прикладного инструм
ентария, средств настр
ойки конфигурации
сист
емы, администрирования Б
Д и сопрово
ждения. Иногда общ
ая стоимость
круп
ных систем, постро
енных на ба
зе реляционных Б
Д, достигает милли
онов
долларов. Осно
вным фактором, опреде
ляющим общую стоим
ость системы, ча
ще
всего явля
ется число поддерж
иваемых пользователей.
51
Н
а уровне технич
еских характеристик разноо
бразие СУБД ещ
е больше,
че
м на качест
венном уровне. К техническим характер
истикам относятся:
• общ
ие параметры (операц
ионная среда, потреб
ность в операт
ивной
памяти, ограни
чения на максим
альный объем Б
Д и д
р.);
• ограничения н
а операции на
д данными;
• ти
пы данных;
• возмож
ности средств формул
ировки и выпол
нения запросов;
• раб
ота в многопользо
вательских средах;
• инструме
нтальные средства разра
ботки приложений;
• имп
орт и эксп
орт.
Оценка производи
тельности производится мето
дом тестирования с
помощью этало
нных тестов и
з набора AS3AP (ANSI SQL Standard Scalable and
Portable). В них контрол
ируется широкий спе
ктр часто встреча
ющихся операций
Б
Д и модели
руются однопользовательские и многопользоват
ельские сре
ды.
В связи с тем, что наша программа хранит информацию в базе данных,
необходимо наличие соответствующей СУБД.
Программа ориентирована на работу с базами данных формата:
1С:Предприятие. СУБД 1С:Проедприятие содержит большое количество
модулей, форм, отчётов для задачи управления персоналом предприятия что нам
подходит. Соответственно на компьютере должна быть установлена данная
СУБД. Если база функционирует на сервере, то необходимо обеспечить
подключение компьютера к серверу. Для работы с базой данных на удаленном
компьютере требуется наличия открытого общего доступа к базе расположенной
на удаленном компьютере, через протокол SMB.
Для удобного взаимодействия пользователя с системой необходимо будет
тщательно продумать интерфейс системы - чтобы он был простой и в то же время
функциональный.
Для оптимального функционирования базы данных необходимо будет
правильно определить логические взаимосвязи между таблицами. Таким образом,
на разработку самой базы данных и основы клиентского приложения может быть
затрачено значительное время.
52
1.4.3. Обоснование проек
тных решений п
о техническому обеспе
чению
Общую струк
туру информационной сист
емы можно рассмат
ривать как
совоку
пность обеспечивающих подси
стем. Техническое обеспе
чение –это
комп
лекс технических сред
ств, предназначенных дл
я работы информа
ционной
системы АИ
С. К насто
ящему времени сложи
лись две осно
вные формы
органи
зации технического обеспе
чения: централизованная и частично ил
и
полностью децентрал
изованная.
Перспективным подх
одом в насто
ящее время счита
ется частично
децентрал
изованный подход, прим
еняя как персон
альные компьютеры, та
к и
боль
шие электронно-вычисли
тельные машины с использованием
распред
еленных сетей. Разрабат
ываемая информационная сист
ема учета
хозяйст
венных операций буд
ет входить в состав ав
томатизированного рабо
чего
места производс
твенного отдела. По
д АИС поним
ается совокупность
инструме
нтальных средств конеч
ного пользователя, включ
ающая техническое и
организационно-методи
ческое обеспечение зад
ач его професси
ональной
деятельности н
а основе персон
альной ЭВМ, установ
ленной на ег
о рабочем мес
те,
работающей ка
к автономно, та
к и в составе вычисли
тельной сети. В настоящее
вре
мя существует множе
ство программных проду
ктов, обеспечивающих
информа
ционные технологии автомат
изации офиса.
К ним относ
ятся текстовые проце
ссоры, табличные проце
ссоры, системы
управ
ления базами дан
ных, электронная поч
та, электронный кален
дарь,
компьютерные конфер
енции, видеотекст, а также специализ
ированные
программы управле
нческой деятельности: веде
ние документов, конт
роль
исполнения прик
азов и т. д.
Изу
чив предметную обла
сть и технич
еское оснащение представи
тельства,
а та
к же перспек
тивные планы н
а будущее, бы
л сделан выв
од – применение
сете
вой технологии в данном слу
чае требует сущест
венные финансовые
влож
ения. Существующее технич
еское оснащение: персон
альный компьютер, и
53
отсутствие компью
терных сетей позво
ляет сделать выв
од, что наиб
олее
приемлемой явля
ется децентрализованная фор
ма организации технич
еского
обеспечени
я.
54
II Проектная часть
2.1. Разработка прое
кта автоматизации
2.1.1. Эта
пы жизненного цик
ла проекта автомат
изации
Понятие жизне
нного цикла явля
ется одним и
з базовых поня
тий
методологии проекти
рования информационных сис
тем. Жизненный ци
кл
информационной сист
емы (ЖЦ ИС) представляет соб
ой непрерывный проц
есс,
начинающийся с момента прин
ятия решения о создании информа
ционной
системы и заканчивается в момент полн
ого изъятия е
е из эксплу
атации.
Жизненный ци
кл информационной сист
емы охватывает вс
е стадии и этапы
е
е создания, сопрово
ждения и разв
ития [10]:
• исследование предм
етной области с последующим формиро
ванием
функциональной и информационной моде
лей объекта, дл
я которого
предназ
начена информационная сист
ема;
• проектирование сист
емы, заключающееся в разработке проек
тных
решений, удовлетв
оряющих всем требов
аниям ТЗ;
• разра
ботку системы (в том чис
ле программирование и тестирование
прикл
адных программ н
а основании проек
тных спецификаций подси
стем,
выделенных н
а стадии проекти
рования);
• тестирование информа
ционной системы и выявление сбо
ев с
послед
ующим их устран
ением;
• развитие сист
емы.
Основные станд
арты ЖЦ И
С:
1. ISO/IEC 12207:1995 (Standard for Information Technology — Software Life
Cycle Processes – «Процессы жизне
нного цикла П
О») определяет общ
ую
структуру жизне
нного цикла П
О в ви
де трехступенчатой мод
ели,
состоящей и
з процессов, вид
ов деятельности и задач.
2. ISO/IEC 15288 «Систе
мная инженерия – Проц
ессы жизненного цик
ла
систем» предна
значен для люб
ого рода сис
тем, созданных челов
еком.
3. ГОСТ 34.601-90 «Автоматиз
ированные системы. Ста
дии создания» –
55
распрост
раняется на автоматиз
ированные системы и устанавливает
ста
дии и эта
пы их созд
ания.
Выбираем для нашей разработки стандарт ISO/IEC 12207:1995, так как
данный стандарт уже стал основой для дальнейшей детализации в методологиях
разработки ПО. Далее необходимо определить стратегию внедрения системы.
Существуют следу
ющие основные страт
егии внедрения сист
емы:
1. Параллельная страт
егия.
При параллельной стратегии одновр
еменно работают ста
рая (ручная) и
новая сист
ема, и и
х выходные докум
енты сравниваются. Ес
ли они соглас
уются
длительное вре
мя, осуществляется пере
ход на нов
ую систему.
2. "Ска
чок".
Эта страт
егия привлекательна, н
о не рекомен
дуется.
3. "Пилотный про
ект".
Это наиб
олее часто исполь
зуемая стратегия. "Пило
тный проекта" - эт
о
тактика "ска
чка", но примен
яемая к огранич
енному числу проце
ссов. Область
приме
нения стратегии - небол
ьшой участок деятел
ьности. Такой под
ход снижает
ри
ск и наиб
олее надежен. Практи
чески все предпр
иятия применяют эт
у тактику
сего
дня.
4. "Узкое мес
то"- это мал
ая часть производс
твенного процесса.
Пр
и использовании пох
ода "узкое мес
то" план внедр
ения выполняется
тол
ько для "узк
ого места" и для люд
ей, работающих в нем. Точн
ость данных
повыш
ается только дл
я изделий в этом "узк
ом месте"; перепод
готовка - только
дл
я людей, работ
ающих в не
м; анализ эффе
кта затрат дела
ется только дл
я него и
т.д. [11].
1. Для нашей разработки выберем стратегию "Пилотный про
ект".
Модель Ж
Ц определяют поря
док исполнения эта
пов в хо
де разработки, а
также крит
ерии перехода о
т этапа к этапу.
Спира
льная (итерационная) мод
ель. Каждый вит
ок спирали соответ
ствует
поэтапной мод
ели создания фрагм
ента или вер
сии программного изде
лия, на не
м
уточняются це
ли и характе
ристики проекта, опреде
ляется его каче
ство,
56
планируются раб
оты следующего вит
ка спирали. В результате выбир
ается
обоснованный вари
ант, который довод
ится до реали
зации.
Достоинства:
1) накоп
ление и повто
рное использование програ
ммных средств, моде
лей
и прото
типов.
2) ориентация н
а развитие и модификацию сист
емы в проц
ессе ее
проекти
рования. 3)анализ рис
ка и изде
ржек в проц
ессе проектирования.
Недос
татки:
1) сложности с определением моме
нта перехода н
а следующий эт
ап.
2) недостаточное вним
ание к разрабат
ываемой документации н
а систему.
В данной работе выбрана методология SCRUM:
• При выборе SCRUM конечный результат не придется долго ждать;
• Вся разработка разбивается на спринты, после каждого спринта уже
будет готов рабочий функционал;
• Основная роль выделена исследователю продукта, представляющему
интересы конечных пользователей.
В качестве модели жизненного цикла была выбрана спиральная модель с
целью постоянной доработки системы в соответствии с желаемыми изменениями.
Заказчик сможет видеть результат работы и помогать формировать видение
дальнейшего развития.
2.1.2 Ожида
емые риски н
а этапах жизне
нного цикла и их опис
ание
Любой про
ект по созд
анию информационной сист
емы предприятия все
гда
включает множе
ство задач, связа
нных с общ
им управлением прое
ктом,
разработкой П
О, проектированием И
С, внедрением, каж
дая из кото
рых сама п
о
себе явля
ется проектом с присущими ем
у особенностями. Поэт
ому в хо
де
разработки сущес
твуют различные рис
ки [11,12].
Риски заказ
чика связаны с неполным достиж
ением целей прое
кта и н
е
эффективно израсход
ованными средствами, а риски исполн
ителя - с
возмож
ностью резкого превы
шения фактической себесто
имости работ п
о
сравнению с плановой. Необход
имость ведения паралл
ельных и под
час