58
MS Visual Studio.
Delphi, ранее Borland Delphi и CodeGear Delphi, – интегрированная среда
разработки ПО для Microsoft Windows наязыке Delphi (ранее носившем название
Object Pascal), созданная первоначально фирмой Borland, и на данный момент при-
надлежащая и разрабатываемая Embarcadero Technologies. EmbarcaderoDelphi явля-
ется частью пакета EmbarcaderoRADStudio и поставляется в четырёх редакциях:
Starter, Professional, EnterpriseиArchitect. Delphi - программный продукт, инстру-
мент быстрой разработки приложений (RAD), интегрированная среда программи-
рования (IDE), система, используемая программистами для разработки программ-
ного обеспечения на языке программирования ObjectPascal.[1]
C++ Builder– программный продукт, инструмент быстрой разработки при-
ложений (RAD), интегрированная среда программирования (IDE), система, исполь-
зуемая программистами для разработки программного обеспечения на языке про-
граммирования C++.
Изначально разрабатывался компанией BorlandSoftware, а затем её подразде-
лением CodeGear, ныне принадлежащим компании EmbarcaderoTechnologies.
C++ Builder объединяет в себе комплекс объектных библиотек (STL, VCL,
CLX, MFC и др.), компилятор, отладчик, редактор кода и многие другие компонен-
ты. Цикл разработки аналогичен Delphi. Большинство компонентов, разработанных
в Delphi, можно использовать и в C++ Builder без модификации, но обратное
утверждение не верно.
C++ Builder содержит инструменты, которые при помощи drag-and-drop дей-
ствительно делают разработку визуальной, упрощает программирование благодаря
встроенному WYSIWYG — редактору интерфейса и пр.
MicrosoftVisualStudio– линейка продуктов компании Майкрософт, включа-
ющие интегрированную среду разработки программного обеспечения и ряд других
инструментальных средств. Данные продукты позволяют разрабатывать как кон-
сольные приложения, так и приложения с графическим интерфейсом, в том числе с
поддержкой технологии WindowsForms, а также веб-сайты, веб-приложения, веб-
службы как в родном, так и в управляемом кодах для всех платформ, поддержива-
емых MicrosoftWindows, WindowsMobile, WindowsCE, .NETFramework,
.NETCompactFramework и MicrosoftSilverlight.
59
VisualStudio включает в себя редактор исходного кода с поддержкой техно-
логии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный
отладчик может работать как отладчик уровня исходного кода, и как отладчик ма-
шинного уровня. Остальные встраиваемые инструменты включают в себя редактор
форм для упрощения создания графического интерфейса приложения, веб-
редактор, дизайнер классов и дизайнер схемы базы данных. VisualStudio позволяет
создавать и подключать сторонние дополнения (плагины) для расширения функци-
ональности практически на каждом уровне, включая добавление поддержки систем
контроля версий исходного кода (как например, Subversion и VisualSourceSafe), до-
бавление новых наборов инструментов (например, для редактирования и визуаль-
ного проектирования кода на предметно-ориентированных языках программирова-
ния или инструментов для прочих аспектов цикла разработки программного обес-
печения (например, клиент TeamExplorer для работы с TeamFoundationServer).
В качестве СУБД используется MicrosoftAccess 2010.
1.4.3. Обоснование проектных решений по техническому
обеспечению.
Программное обеспечение разрабатывается для персональной ЭВМ (IBM
PC-совместимой) со следующими характеристиками:
процессор с частотой не ниже 1,5 ГГц;
объем ОЗУ не менее 512 Мб;
графический адаптер SVGA;
стандартная клавиатура;
манипулятор типа «мышь» или совместимый с ним;
сетевой адаптер (при использовании программы в сетевом режиме);
объем дискового пространства для программного модуля не менее 8Mb;
объем дискового пространства, занимаемого базой данных, зависит от ко-
личества хранящейся в ней информации;
операционная система Windows 7/8.
60
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного обеспечения– ряд событий, происходящих с
системой в процессе ее создания и дальнейшего использования. Говоря другими
словами, это время от начального момента создания какого либо программного
продукта, до конца его разработки и внедрения. Жизненный цикл программного
обеспечения можно представить в виде моделей.
Модель жизненного цикла программного обеспечения — структура, содер-
жащая процессы действия и задачи, которые осуществляются в ходе разработки,
использования и сопровождения программного продукта.
Эти модели можно разделить на 3 основные группы:
1. Инженерный подход.
2. С учетом специфики задачи.
3. Современные технологии быстрой разработки.
Рассмотрим существующие модели (подклассы) и оценим их преимущества
и недостатки.
Модель кодирования и устранения ошибок
Совершенно простая модель, характерная для студентов ВУЗов. Именно по
этой модели большинство студентов разрабатывают, ну скажем лабораторные ра-
боты.
Данная модель имеет следующий алгоритм:
1. Постановка задачи.
2. Выполнение.
3. Проверка результата.
4. При необходимости переход к первому пункту.
Модель устаревшая. Она характерна для 1960-1970 гг., поэтому преиму-
ществ перед следующими моделями практически не имеет, а недостатки видны
сразу. Относится к первой группе моделей.
61
Каскадная модель жизненного цикла программного обеспечения (водопад).
«Алгоритм данного метода, который представлен в соответствии с рисунком
21, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет
и ряд весомых недостатков.
Рисунок 21 – Каскадная модель жизненного цикла
Преимущества:
последовательное выполнение этапов проекта в строгом фиксированном
порядке;
позволяет оценивать качество продукта на каждом этапе.
Недостатки:
отсутствие обратных связей между этапами;
не соответствует реальным условиям разработки программного продукта;
Относится к первой группе моделей.
Каскадная модель с промежуточным контролем (водоворот)
Данная модель является почти эквивалентной по алгоритму предыдущей мо-
дели, однако при этом имеет обратные связи с каждым этапом жизненного цикла,
при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на
разработку. Относится к первой группе моделей.
V модель (разработка через тестирование)
Данная модель, представленная в соответствии с рисунком 22, имеет ближе
приближенная к современным методам алгоритм, однако все еще имеет ряд недо-
статков. Является одной из основных практик экстремального программирования.
62
Рисунок 22 – V модель (разработка через тестирование)
Модель на основе разработки прототипа
Данная модель основывается на разработки прототипов и прототипирования
продукта.
Прототипирование используется на ранних стадиях жизненного цикла про-
граммного обеспечения:
1. Прояснить не ясные требования (прототип UI).
2. Выбрать одно из ряда концептуальных решений (реализация сценариев).
3. Проанализировать осуществимость проекта.
Классификация протопипов:
1. Горизонтальные и вертикальные.
2. Одноразовые и эволюционные.
3. Бумажные и раскадровки.
Горизонтальные прототипы — моделирует исключительно UI, не затрагивая
логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.
Модель принадлежит второй группе.
63
Спиральная модель жизненного цикла программного обеспечения
Спиральная модель представляет собой процесс разработки программного
обеспечения, сочетающий в себе как проектирование, так и постадийное прототи-
пирование, представленная в соответствии с рисунком 23, с целью сочетания пре-
имуществ восходящей и нисходящей концепции.
Рисунок 23 – Спиральная модель
Преимущества:
быстрое получение результата;
повышение конкурентоспособности;
изменяющиеся требования — не проблема.
Недостатки:
отсутствие регламентации стадий.
б
а
з
у
У
с
о
в
е
р
ш
е
н
с
т
в
о
в
а
н
и
е
о
б
р
а
б
о
т
к
и
д
а
н
н
о
г
о
к
о
м
п
л
е
64
Третьей группе принадлежат такие модели как экстремальное программиро-
вание (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел расска-
зать отдельно
10
.
Для жизненного цикла автоматизации рабочего места кассира была вы-
брана спиральная модель, так как для разрабатываемой системы больше под-
ходит поэтапная разработка.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некото-
рых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы, закреплен-
ные в стандарте, в большей степени соответствуют каскадной модели жизненного
цикла.
ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описа-
ния фаз, стадий и этапов.
CustomDevelopmentMethod (методика Oracle) по разработке прикладных
информационных систем - технологический материал, детализированный до уров-
ня заготовок проектных документов, рассчитанных на использование в проектах с
применением Oracle. Применяется CDM для классической модели ЖЦ (предусмот-
рены все работы/задачи и этапы), а также для технологий "быстрой разработки"
(FastTrack) или "облегченного подхода", рекомендуемых в случае малых проектов.
RationalUnifiedProcess (RUP) предлагает итеративную модель разработ-
ки, включающую четыре фазы: начало, исследование, построение и внедрение.
Каждая фаза может быть разбита на этапы (итерации), в результате которых вы-
пускается версия для внутреннего или внешнего использования. Прохождение че-
рез четыре основные фазы называется циклом разработки, каждый цикл завершает-
ся генерацией версии системы. Если после этого работа над проектом не прекраща-
10
Модели жизненного цикла программного обеспечения. // https://habrahabr.ru/post/111674/
65
ется, то полученный продукт продолжает развиваться и снова минует те же фазы.
Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
MicrosoftSolutionFramework (MSF) сходна с RUP, так же включает четы-
ре фазы: анализ, проектирование, разработка, стабилизация, является итерацион-
ной, предполагает использование объектно-ориентированного моделирования.
MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений.
ExtremeProgramming (XP). Экстремальное программирование (самая но-
вая среди рассматриваемых методологий) сформировалось в 1996 году. В основе
методологии командная работа, эффективная коммуникация между заказчиком и
исполнителем в течение всего проекта по разработке ИС, а разработка ведется с
использованием последовательно дорабатываемых прототипов.
Стандарт ISO/IEC серии 15288
В стандарте ISO/IEC 12207 не предлагается конкретной модели жизненного
цикла и методов разработки, его рекомендации являются общими для любых моде-
лей жизненного цикла. Под моделью обычно понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач на
протяжении жизненного цикла.
В данной дипломной работе выбран стандарт ISO/IEC 12207, т.к. он не
содержит описание содержания работ на каждом этапе.
В общем случае считается, что внедрение любой информационной системы
включает в себя инсталляцию (установку) и настройку, как оборудования, так и но-
вого обеспечения с последующей сдачей полученной системы в промышленную
эксплуатацию. При этом существует несколько стратегий внедрения ИС:
параллельное использование;
скачок;
пилотный проект;
узкое место.
Параллельное использование подразумевает одновременную работу старой
возможно традиционной ручной и новой автоматизированной системы. Они могут
согласованно существовать длительное время, после чего осуществляется оконча-
тельный переход на новую систему.
66
Скачок означает, что прежняя система еще вчера работала, а сегодня в орга-
низации перешли на новую систему.
Пилотный проект, по сути, представляет собой тактику «скачка», но приме-
няемую к ограниченному числу процессов. То есть обычно он используется на не-
большом участке деятельности. Такой подход снижает риски и наиболее надежен.
Практически большинство организаций применяют эту тактику.
Узкое место − это малая часть некоторого процесса. При использовании та-
кого похода внедрение автоматизированной информационной системы выполняет-
ся только для конкретного «узкого места» и работающих на нем людей.
Причем эффективность обычно повышается только на этом участке.
В данной работе наиболее оптимален пилотный проект.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
«Любой проект по созданию информационной системы предприятия всегда
включает множество задач, связанных с общим управлением проектом, разработ-
кой ПО, проектированием ИС, внедрением, каждая из которых сама по себе явля-
ется проектом с присущими ему особенностями. Поэтому в ходе разработки суще-
ствуют различные риски.
Риски заказчика связаны с неполным достижением целей проекта и не эф-
фективно израсходованными средствами, а риски исполнителя - с возможностью
резкого превышения фактической себестоимости работ по сравнению с плановой.
Необходимость ведения параллельных и подчас принципиально отличающихся по
своему характеру работ приводит к тому, что многократно возрастает уровень рис-
ка проекта.
Наиболее характерные риски и методы из минимизации приведены в табли-
це 6.
Таблица 6– Возможные риски проекта и способы их минимизации
Виды рисков/
варианты
менеджмента рисков
Снижение видов риска
Снижение вероятности
возникновения риска
Риски, связанные с мас-
штабом проекта
Детальный анализ каждо-
го этапа работ, взаимо-
действия участников, ор-
Детально проработанная
программа качества, отра-
ботанное управление кон-
67
Виды рисков/
варианты
менеджмента рисков
Снижение видов риска
Снижение вероятности
возникновения риска
ганизации работ.
фигурацией проекта, специ-
альные процедуры взаимо-
действия участников.
Риски, связанные с не-
достаточным опытом в
сфере ИТ
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы.
Разработка и утверждение
концепции проекта на воз-
можно более ранней его
стадии.
Технические риски про-
екта
Строгий отбор проектной
команды по квалификаци-
онным критериям. Обуче-
ние участников проекта
технологии проектных
работ, инструментальным
средствам.
Использование стандартов
предприятия на проектные
работы, разработка стан-
дартов проекта.
Организационные риски
проекта
Обучение участников
проекта (курс "управление
проектом"), тренинги ко-
манды, как можно более
полная формализация де-
ятельности.
Включение в команду ад-
министратора проекта, де-
тальное распределение ро-
лей в проекте.
Операционные риски
проекта
Многократное тестирова-
ние созданных продуктов,
тщательная экспертиза
документов.
Строгое выполнение проце-
дур программы качества.
Источник»
11
11
Автоматизация регистрации и мониторинга заявок от контрагентов. // http://www.bestreferat.ru/referat-181302.html