42
Именно поэтому для проекта выбрана MySQL.
Для создания рабочих программ под Windows есть множество
интегрированных сред разработки. К ним обычно относят Visual Basic,
Visual С+ +, Delphi, С+ + Builder.
После создания средств быстрой разработки приложений (Rapid
Application Development – RAD) стало возможно программировать при
помощи готовых шаблонов и компонентов. Для примера сравним Delphi и
C++ Builder, а также выберем среду программирования для будущей
автоматизированной системы [35].
Средство визуального программирования Delphi было создано
фирмой Borland International на основе языка Object Pascal. ООП к
созданию компонент стал серьезным шагом в будущее. Еще один
выигрыш основывался на нормальной компиляции, что позволяет
получить более производительные программы. Первые версии Delphi
быстро завоевали уважение не только в ВУЗах, где лидером был Pascal, но
и у профессиональных программистов. Этот факт подтолкнул одно из
подразделений Borland International перенести визуальную технологию в
среду C++. И почти одновременно с выходом Delphi 2.0 на рынок пришла
первая версия Borland C++ Builder (ВСВ). Базовую часть первой версии
ВСВ включала библиотека визуальных компонент VCL (Visual Component
Library), заимствованная без изменений из Delphi 2. Интерфейсы сред
Delphi и ВСВ очень похожи друг на друга, да и большая часть ВСВ была
создана на языке Object Pascal на базе Delphi. Именно из-за своего
происхождения система ВСВ оказалась двуязычной. Кроме базового языка
программирования она давала возможность практически без каких-либо
кардинальных изменений применять формы, объекты и модули, созданные
в среде Delphi [35]. Чтобы еще больше увеличить сферу влияния среды
ВСВ, ее разработчики в более поздних версиях реализовали возможность
применения библиотеки классов MFC (Microsoft Foundation Classes) от
известной компании Microsoft.
43
Delphi 7 2010 г является прекрасным инструментом, но в то же время
и сложной программной средой, состоящей из множества элементов.
Включает в себя новый интерфейс Galileo, а еще interbase server и desktop,
remote debugger server, Model Maker, Install Shield.
Особенно интересными в Delphi являются возможности объектно-
ориентированного подхода к программированию, ее
высокопроизводительный компилятор, отличная поддержка баз данных,
тесная интеграция с программированием под ОС Windows и технология
компонентов.
Но главной частью является язык Object Pascal, на котором
базируется все остальное.
Delphi 7 2010 г имеет открытую архитектуру, полностью
адаптирован с технологиями Microsoft OLE Automation, ActiveX, ODBC.
Компилятор позволяет реализовать доступ ко всем ресурсам ОС с
поддержкой интерфейса Win32 (Windows ХР, 7).
Программы Delphi применяют объектно-ориентированную
структуру, названную VCL – Visual Component Library (библиотека
визуальных компонентов). Благодаря VCL быстрая разработка
приложений поднимается на новый уровень. Можно значительно
увеличить свои возможности за счет реализации своих собственных
компонентов. Тем более многие независимые поставщики на сегодняшний
день уже реализовали множество аналогичных компонентов.
Delphi 7 2010г имеет большое количество других улучшений IDE,
расширенную поддержку баз данных, обновленную версию MIDAS с
поддержкой Интернета, механизм управления версиями TeamSours,
поддержку перевода, концепцию фреймов и огромное количество
остальных полезных компонентов.
Исходя из всего вышесказанного и результатов анализа экспертным
оцениванием делаем выбор среды программной разработки в пользу
Delphi, обеспечивающем чрезвычайно высокую скорость работы и
44
простоту использования.
2.3 Разработка проекта автоматизации, описание возможных
рисков
Жизненный цикл программного обеспечения (ПО) определяет
период времени, наступающий с момента принятия решения о важности
разработки ПО и оканчивающийся в момент его фактического изъятия из
пользования. Этот цикл — процесс создания и эволюции ПО.
Понятие ЖЦ ПО пришло тогда, когда разработчики осознали
важность перехода от единоличных кустарных методов разработки
программ к технологичному промышленному их созданию. И зачастую в
подобных ситуациях многие пытаются перенести в свою сферу опыт их
других направлений производства. Таким образом было перенято понятие
ЖЦ.
Главные этапы ЖЦ ПО:
Исследование требований,
Построение макета,
Программирование,
Отладка и исправление ошибок,
Внедрение и использование.
Нюансом разработки ПО становится принятие решений на
первичных этапах с их реализацией на заключительных этапах. Ошибки в
требованиях к ПО могут привести не только к потерям в процессе создания
и использования, но и к полному провалу проекта. Корректировка и
изменения в спецификациях ПО зачастую влечет за собой повторение всех
следующих этапов построения модели и реализации ПО.
Сам ЖЦ ПО является непрерывным процессом, начинающимся в
момент принятия решения о важности его создания и оканчивающимся в
момент его окончательного выведения из эксплуатации.
45
Главный нормативный документ, контролирующий ЖЦ ПО –
международный стандарт ISO/IEC 12207 (ISO, International Organization of
Standardization – Общемировая компания по стандартизации, IEC,
International Electrotechnical Commission – Международная коллегия по
электротехнике). Он отражает структуру ЖЦ, включающую в себя
процессы, действия и задачи, реализуемые за время разработки ПО.
Исходя их этого стандарта, структура ЖЦ ПО основана на 3 группах
процессов (рисунок 9):
Рисунок 9 Структура ЖЦ ПО
Любой такой процесс определяется некоторыми задачами и
методами их решения, начальными данными, приобретенными на
предыдущем этапе, и результатами. Итогами анализа, к примеру,
становятся функциональные и информационные модели, а также
соответствующие им диаграммы. ЖЦ ПО носит итерационный характер:
итоги прошедшего этапа влекут изменения в проектных решениях,
основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всё
вышесказанное можно отнести и к ИС.
46
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач
в рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и
трудности проекта и конкретных условий, в которых система развивается и
работает.
Сегодня наибольшее распространение получили три базовые модели
ЖЦ:
Задачная модель;
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор
этапов, работ и операций в порядке их реализации и взаимосвязях,
определяющих ведение работ от составления технического задания до
финальных испытаний ряда версий и завершения эксплуатации ПС или
ИС. Подобные стандарты состоят из правил описания начальной
информации, методики выполнения операций, осуществляют контроль
технологических процессов и правил представления их результатов. Еще
они определяют содержание технологических и эксплуатационных
документов на комплексы ПО. Они выражают организационную структуру
коллектива, поддерживают распределение и планирование заданий,
реализуют контроль над этапами разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт
ISO 12207, как стандарт, включающий в себя большинство
автоматизированных систем (АС) и ПС, где ПС – малая часть всего плана
работ. Международный стандарт ISO/IEC 12207 показывает стратегию и
общий порядок в разработке и использовании ПО, он охватывает ЖЦ ПО
от зарождения идей до окончания цикла. Определение стандарта: система
— это совокупность одного или более процессов, аппаратных средств, ПО,
47
оборудования и людей для реализации возможности удовлетворения
конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и
покупатель (клиент). Применяется в разных случаях, даже когда обе
стороны внутри одной компании. В отличии от CDM, стандарт ISO
состоит из более крупных обобщенных процессов: «покупка», «доставка»,
«создание» и т.п. Любой процесс разделен на набор действий, а каждое
действие — на совокупность задач. Важно одно отличие ISO: любой
процесс, действие или задача определяется и реализуется другим
процессом по мере необходимости, причем нет ранее заданных
последовательностей (конечно, в рамках сохранения логики связей по
начальным сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в
случае необходимости вызывает другой или его часть. Стандарт отражает
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также указывает
список необходимых работ и подробно описывает содержание каждой из
них. Архитектура ЖЦ ПС в стандарте основывается на 3 основных
компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также
заготовки решений или документации. Он отражает архитектуру
процессов ЖЦ ПО, но не углубляется в детали реализации или выполнения
услуги и задачи, включенных в процессы. Стандарт не указывает
конкретную модель ЖЦ или метод создания ПО, но показывает, что
стороны участники использования стандарта несут ответственность за
выбор модели ЖЦ для проекта ПО, за подгонку процессов и задач
48
стандарта к этой модели, за обоснованный выбор и использование методов
создания ПО, за реализацию действий и задач, уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
заключается договор, корректируются его условия и требования.
Участники этапа – ответственный от лица заказчика, который
контролирует и уточняет направления для разработчиков. А так же
менеджер проекта от лица разработчиков. Он принимает от заказчика
требования, подписывает договор, и согласует начальные установки и
задачи для работы. На этом этапе заказчик должен предоставить
развернутое техническое задание (ТЗ), менеджер утверждает его,
уточняются некоторые детали задания и согласовываются средние сроки
выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика,
и в договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
На каждом этапе жизненного цикла ИС есть различные риски. Они
приводят как к серьезным неустойкам во в процессе разработки системы,
так и в ее функциональных возможностях.
49
Далее будут представлены риски в зависимости от процессов ЖЦ, а
также возможные методы их предотвращения.
Процесс подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в группу разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых процессов производства;
• Неимение выработанной стратегии автоматизации;
• Несогласованность в общих целях и задачах проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и
консультантов;
• Четкая формулировка целей и задач;
• Выработка определённой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки
проекта.
Риск ведения проекта
Риски:
• Ошибочная установка границ и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методологий решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
50
• Поддержка стабильности границ проекта, которые выделяются
еще на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Малоэффективный план организации разработки системы;
• Несоблюдение сроков реализации работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый
доступ к этим данным для всех участников проекта.
Процесс разработки
Риск персонала
Риски:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными
системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы взаимодействия между
сотрудниками, полное документирование изменений в системе.
Технические риски
51
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация состоит из описания лишь
некоторых функций системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
Процесс внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчиков и экспертов
предметной области;
• Отсутствие желания у сотрудников использовать новую
систему и связанные с этим сложности их обучения;
• Безучастность руководства.
Методики предотвращения:
• Обучение пользователей со стороны заказчика методики
работы с системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;
• Привлечение руководящего персонала в проект и активное
взаимодействие с ним во время проведения всего проекта.
Технические риски
Риски:
• Утрата информации при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, которые имеют опыт
разработки подобных систем.
Процесс эксплуатации и сопровождения