46
зов с ежеминутным выборочным опросом программы базы данных на присут-
ствие свежих заказов в основе, а еще загруженности сетевой инфраструктуры на
30 процентов и загруженности коллективного сервера баз данных на 25 процен-
тов, нет надобности закупать высокопроизводительный сервер с сетевым адап-
тером скоростью в 1Gbps, довольно ограничиться интерфейсом в 100 Mbps. Ито-
гом анализа критериев по серверному оборудованию будет использование того
же сервера, который использовался в компании ранее. В качестве сервера баз
данных (БД) используется сервер, построенный на платформе HP ProLiant
DL365 G5, он обладает следующими характеристиками, представленными в таб-
лице 1.9
Таблица № 1.9
Характеристики сервера БД.
Характеристика
Значение
Процессор
Двуядерный Intel® Xeon® X5260 с тактовой частотой
3,3 Гц.
Кол-во процессоров
8
Оперативная память
16 Гб (расширяемая до 64Гб)
Жесткие диски
Тип «SAS» 4 диска 300 Гб и 2 диска 74 Гб
Кол-во жестких дис-
ков
6 (расширяемо до 8)
Питание
Дополнительно резервный блок питания 800 Вт с горя-
чей заменой
Рассмотрим данную платформу подробнее:
Два процессора позволяют, при использовании SQL сервера, эффектив-
но распараллеливать задачи, выполняемые на сервере.
16 Гб оперативной памяти достаточно для обработки больших объемов
информации, используемых на данный момент в БД, а также последующего уве-
личения вычислительной нагрузки, так как на данный момент пиковый размер
занятой оперативной памяти составляет 6 Гб.
Использование 6 жестких дисков обусловлено следующими соображе-
ниями:
47
Для достоверного функционирования операционной системы сервера
санкционирован RAID массив из 2-ух строгих дисков объемом по 74 ГБ (такого
размера довольно для работы ОС). Операционная система нарочно размещена
порознь от файлов БД из мнения защищенности и производительности.
Для достоверного сбережения данных в формате Structured Query
Language (SQL) санкционирован массив строгих дисков наибольшего размера
300 Гб. Предоставленного размера довольно для внедрения свежего перечня
возможностей, на данный момент размер занятого места занимает 53Гб, при
условии того собственно, что в БД хранятся записи за 3 года.
Так же отдельно необходимо хранить данные в форматах mdf (файл базы
данных), а также транзакции в виде файлов ldf (файл транзакций), для чего не-
обходим еще один массив, аналогичный предыдущему по размеру.
Использование дополнительного питания повышает отказоустойчивость
системы.
Для ПК-пользователя и ПК-инженера основными критерием выбора обо-
рудования в данном случае являются его технические характеристика, и что не
менее важно, соответствие утвержденным корпоративным стандартам. Таким
образом, для персональных компьютеров основным критерием выбора является
утвержденный список конфигураций ПК. (B6000-ITX: Core i3-9100/ 8 Гб/ 1 Тб/
UHD Graphics 630) Характеристики данной конфигурации описаны в таблице
1.10
Таблица № 1.10
Характеристика конфигурации ПК пользователя.
Наименование
Конфигурация
Корпус
DeskTop INWIN BM639 <Black> Mini-iTX/Mini-DTX 160W
(24+4пин)
Процессор
CPU Intel Core i3-9100 3.6 GHz/4core/SVGA UHD Graphics
630/1+6Mb/65W/8 GT/s LGA1151
Куллер для про-
цессора
DEEPCOOL <DP-ICAP-T9P> THETA 9 PWM (4пин, 1155,
17.8-41.3дБ, 1100-3200об/мин, Al)
Вентилятор
GlacialTech "SilentBlade II GT9225-EDLA1" d90мм,
1600об./мин. (OEM)
48
Продолжение таблицы № 1.10
Наименование
Конфигурация
Материнская плата
GIGABYTE H310M S2V 2.0 (RTL) LGA1151 <H310>
PCI-E Dsub+DVI GbLAN SATA MicroATX 2DDR4
Модуль оператив-
ной памяти
Crucial <CT8G4DFS8266> DDR4 DIMM 8Gb <PC4-
21300> CL19
Жесткий диск
HDD 1 Tb SATA 6Gb/s Seagate Barracuda
<ST1000DM010> 3.5" 7200rpm 64Mb
Привод DVD±RW
DVD RAM&DVD±R/RW&CDRW ASUS DRW-24D5MT
<Black> SATA (OEM)
49
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы Жизненного Цикла проекта автоматизации
Жизненный цикл разработки программного обеспечения (ЖЦ) - это про-
цесс, используемый индустрией программного обеспечения для проектирования,
разработки и тестирования высококачественного программного обеспечения.
ЖЦ нацелен на производство высококачественного программного обеспечения,
которое соответствует ожиданиям клиентов или превосходит их, в кратчайшие
сроки завершает работу и оценивает затраты.
ЖЦ является аббревиатурой жизненного цикла разработки программно-
го обеспечения.
Это также называется процессом разработки программного обеспече-
ния.
ЖЦ - это структура, определяющая задачи, выполняемые на каждом
этапе процесса разработки программного обеспечения.
ГОСТ Р ИСО/МЭК 12207-2010 является международным стандартом
для процессов жизненного цикла программного обеспечения. Он призван стать
стандартом, определяющим все задачи, необходимые для разработки и обслужи-
вания программного обеспечения.
ЖЦ это процесс, которому следует программный проект в рамках органи-
зации программного обеспечения. Он состоит из подробного плана, описываю-
щего, как разрабатывать, поддерживать, заменять и изменять или улучшать кон-
кретное программное обеспечение. Жизненный цикл определяет методологию
улучшения качества программного обеспечения и общего процесса разработки.
[9]
Custom Development Method (методика Oracle) по разработке прикладных
информационных систем под заказ - конкретный материал, детализированный
до уровня заготовок проектных документов, рассчитанных на использование в
проектах с применением Oracle. Степень адаптивности CDM ограничивается
тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и эта-
50
пы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в
случае малых проектов и возможности быстро прототипировать приложения.
RUP был разработан на основе результатов сотни различных проектов по
разработке программного обеспечения и идеи некоторых из наиболее влияющих
на людей в программной инженерии дисциплины. XP представляет гибкие мо-
дели процесса. MSF была разработана на основе большого опыта Microsoft со-
бранном на протяжении десятилетий.
RUP, процесс доступен как продукт, становится объектом частой практи-
ки в отрасли за последние годы и был расширен для поддержки элементов XP.
Microsoft продвигает свою Framework систему, включив ее в предстоящем
выпуске системы Visual Studio Team и следует примеру Rational, предоставляя
не только описание процесса, но и полный продукт для его поддержки.
Rational Unified Process является наиболее часто используемым процессом
разработки программного обеспечения в промышленности. Основными пре-
имуществами являются поддержка через Rational Software, которая постоянно
совершенствует процесс, поддержка инструмента и плотно соединенную ин-
струмент документацию, а также поддержку Rational для наставничества в реа-
лизации процесса. RUP обеспечивает хорошо структурированную основу, разде-
ленную на фазы и рабочие процессы, что обеспечивает легкую навигацию в рам-
ках структуры. Обеспечивает команде разработчиков свободный доступ к базе
знаний с инструкциями для использования программных средств. Процесс
включает в себя комплексные меры по обеспечению качества. Минимальные
стандарты к требованиям проектирования и разработке программного итераци-
онного обеспечения включены, а также тестирование, управление конфигураци-
ями и взаимодействие с клиентом в течение всего процесса.
Framework Microsoft Solution обеспечивает глубокое понимание разработ-
ки программного обеспечения практикуемого в Microsoft. MSF представляет со-
бой попытку распространять компанией Microsoft свои знания в области разра-
ботки программного обеспечения. MSF является одной из двух дополняющих
друг друга структур (кроме Microsoft Operations Framework (MOF)), образуя
комплексное решение для крупных софтверных компаний, занятых в средних и
крупных проектах. Тем не менее, MSF может применяться самостоятельно. Она
51
не зависит от финансового отдела, что обеспечивает легкую реализацию в сред-
них компаниях. Благодаря своей гибкости, масштабируемости и отсутствию
жестких инструкций MSF способен удовлетворить нужды организации или про-
ектной группы любого размера. Оба принципа не только улучшают качество
программного обеспечения, но и то, как оно построено. Microsoft предоставляет
несколько моделей шаблонов, рекомендованных в MSF. Поскольку MSF не
включает в себя огромный набор рекомендуемых средств (которые будут ме-
няться с следующей версией Visual Studio), она может быть легко интегрирована
в существующую среду разработки. [10]
Экстремальное программирование представляет собой совершенно новый
подход к разработке программного обеспечения. Для небольших проектов, XP
предлагает хороший подход для достижения высокого качества программного
обеспечения. Тесное вовлечение клиента, основное внимание на тестировании, и
подход к снижению ИКР поддержки этой цели. Тем не менее, XP может приве-
сти к организационным проблемам при применении в больших проектах. Для
большинства проектов, трудно достичь тесную интеграцию клиента в процессе
разработки.
Основные критерии для выбора стандарта ЖЦ будут в таблице 2.1.
Итерация – для того, чтобы установить более высокое качество программ-
ного обеспечения, процесс разработки ПО должен использовать итеративный и
инкрементный подход к развитию. Итерационные циклы включают все виды де-
ятельности в области развития анализа, проектирования, реализации, тестирова-
ния и, наконец, развертывания. Контроль качества может применяться более эф-
фективно в течение всего процесса. При использовании итеративного подхода,
процесс приобретает большую гибкость при работе с изменяющимися требова-
ниями или областью. Выпуски продукта ранней обратной связи от клиентов и
заинтересованных сторон, которая имеет жизненно важное значение для улуч-
шения общего качества программного обеспечения. Однако, итеративная разра-
ботка должна быть поддержана управлением рисками и ранним вовлечением ко-
нечных пользователей для достижения своего полного потенциала. XP основы-
вается на очень строгом итеративном подходе, требующем ежедневную сборку
всех компонентов. Это ограничивает время, необходимое для обнаружения оши-
52
бок разработчиками и своевременного решения этих проблем. Конечно, непол-
ные компоненты или отдельные методы исключены из ежедневной сборки.
Структура декомпозиции работ должна рассмотреть эти вопросы, чтобы позво-
лить интеграцию мелких компонентов каждый день. Использование этого под-
хода требует тщательного планирования, но, безусловно, обеспечивает высокое
качество программного обеспечения.
Качество как цель – в процессе разработки программного обеспечения
необходимо определить качество как основную цель улучшения общего качества
программного обеспечения. Целевые показатели качества должны быть опреде-
лены и задокументированны с участием команды проекта и клиента. Это гаран-
тирует, что цели и качество станут достижимыми и измеримыми. MSF определя-
ет качественные цели проекта в начале и подчеркивает выполнение этих целей в
качестве основной части проекта.
Непрерывная проверка качества – это набор процедур, которые докумен-
тируют каждое изменение в ходе проекта, необходимое, чтобы окончательно га-
рантировать качество. Не только отчеты о состоянии проекта, но и оценки теку-
щей деятельности и возможных изменений необходимых для выявления про-
блем, как можно скорее. Для поддержки этих процедур, каждый проект нужда-
ется в определенном процессе управляемых изменений. Все эти действия могут
быть реализованы в виде поддерживающих действий рабочих процессов. Непре-
рывная проверки качества включает в себя тщательное тестирование. Кроме
внутреннего тестирования, внешние приемочные испытания с клиентом необхо-
димы также для того, чтобы убедиться, что продукт отвечает потребностям и
требованиям заказчика. Поэтому процесс разработки программного обеспечения
должен включать в себя рабочий процесс тестирования на протяжении всего
процесса, в том числе внешних испытаний с конечными пользователями, чтобы
обеспечить высокое качество программного обеспечения.
Требования заказчика – процесс разработки программного обеспечения
основывается на четкой структуре и методологии требовать с заказчика доку-
мент. Он также должен интегрировать эти требования в полном процессе. Выяв-
ление требований является одним из наиболее сложных программных обеспече-
ний инженерных дисциплин. Потребности и пожелания клиента, которые обыч-
53
но не имеют глубоких технических знаний, должны быть документированы, так
чтобы разработчики могли создавать приложения на основе этой информации.
Таким образом, необходимо, чтобы команда проекта понимала клиента и его
бизнес. В противном случае будет невозможно правильно реализовать потребно-
сти клиентов. Процесс разработки программного обеспечения должен сосредо-
точиться на требованиях на протяжении всего проекта. Выявление и документи-
рование требований в начале не является достаточным. Кроме того, процесс раз-
работки программного обеспечения должен гарантировать, что не только клиент,
но и конечные пользователи участвуют в процессе формирования требований.
Успех проекта сильно зависит от этих двух групп: первая покупка продукта, а
вторая, его использование. Процесс разработки программного обеспечения дол-
жен определить процедуры для подготовки конечных пользователей использо-
вать конечный продукт.
Архитектура системы – в современных разработках программного обеспе-
чения, архитектура системы оказывает значительное влияние на общее качество
продукта. Одной из причин этого является интеграция в существующие системы
программной среды, как большая часть сегодняшнего развития программного
обеспечения. Повторное использование приобретает все большее значение в свя-
зи с увеличением времени и давления на затраты.
Фокус на команде – команда должна рассматриваться как совокупность
равноправных лиц, которые вместе несут ответственность за качество и успеш-
ность проекта. Когда ответственность за неудачи может быть отнесена к одному
человеку, успех проекта не может быть гарантирован. Сосредоточение на сов-
местную работу повышает мотивацию участников проекта, так как все это рас-
сматривается как столь же важной частью проекта. Это в конечном итоге приво-
дит к высокой идентификации членов команды с продуктом. Очевидно, что мо-
тивированные члены команды способствуют высокому качеству, поскольку они
работают более концентрированно и добросовестно. Процесс разработки про-
граммного обеспечения должен включать четко определенную структуру коман-
ды, в том числе эффективной постановки задач и четких руководящих принци-
пов коммуникации. MSF присваивает значение равного по каждому члену ко-
манды и роли: полная команда имеет шесть целей для достижения и может рас-
54
сматриваться как мощная реализация принципа фокуса команды. В большинстве
проектов некоторые цели имеют более высокое значение, чем другие. Менедже-
ры решают самостоятельно или возлагают ответственность за неспособность
членов своей команды. MSF «команда коллег» концепция позволяет избежать
этих проблем и позволяет проекту получить прибыль от всех возможностей кол-
лективной работы.
Парное программирование – парное программирование тесно связано с
акцентом на команды, но было выбрано в качестве другого критерия оценки, по-
скольку оно было недооценено за свой вклад в высокое качество в прошлом. XP
демонстрирует, как два разработчика могут дополнять друг друга, а не мешать
друг другу. Один разработчик реализует текущий метод, а другой работает над
вопросами интеграции. Такой подход экономит время и минимизирует количе-
ство ошибок. Лучшее решение, более вероятно, так как два человека, скорее все-
го, имеют разные точки зрения той же проблемы и, следовательно, дополняют
друг друга в ее решении.
Управление требованиями – процесс разработки программного обеспече-
ния должен быть определен и формализован на пути относительно его примене-
ния к широкому набору проектов. Процесс, который концентрируется на не-
большом или специализированном наборе проектов гарантирует высокое каче-
ство в конкретной среде. Основной целью процесса является применение многих
проектов внутри компании, не снижая его прочности. Процесс должен быть
адаптирован к различным проектам на основе ее основных элементов. Для того,
чтобы охватить всю сложность типовых проектов, заданный набор основных
элементов должен быть сохранен. Большое количество основных элементов, не
обязательно улучшат качество конечного продукта. Поэтому процессы разра-
ботки программного обеспечения должны опираться на основные элементы. Ос-
новываясь на этих основных элементах, необходимо определить методы инте-
грирования процесса к типу проекта и размер проекта.
Конфигурация и управление изменениями – хорошо функционирующая
конфигурация и управление изменениями (КЗУ) является важной частью обес-
печения качества программного обеспечения. Существование или не существо-
вание КЗУ оказывает наибольшее влияние при обслуживании программного
55
обеспечения и развития, все же основы для КЗУ (надлежащей документации, ко-
да архивов источника и т.д.) должны быть установлены в процессе разработки.
Управление рисками – это процесс принятия и выполнения управленче-
ских решений, направленных на снижение вероятности возникновения неблаго-
приятного результата и минимизацию возможных потерь, вызванных его реали-
зацией. В рамках управления рисками осуществляется количественная и каче-
ственная оценка вероятности достижения предполагаемого результата, неудачи
и отклонения от цели.. MSF представляет свою собственную модель управления
рисками. Она, следовательно, делает акцент на дисциплине, придавая этому
важное значение для поддержания проекта на пути улучшения общего качества
разработки. Управление рисками, как собственная дисциплина, является крите-
рием для любого процесса разработки программного обеспечения с акцентом на
улучшение качества программного продукта. Управление рисками в рамках
встреч и других дисциплин предполагает, что идентификация и управление рис-
ками становится менее важным, поскольку проектная группа занята другими
проблемами. Проект становится восприимчивым к факторам риска.
Таблица № 2.1
Критерии для выбора стандарта
Критерий
MSF
RUP
XP
Итерация
+
+
+
Качество как цель
+
-
-
Непрерывная проверка качества
+
+
+
Требования заказчика
+
+
+
Архитектура системы
+
+
+
Фокус на команде
+
+
+
Парное программирование
-
-
+
Управление требованиями
+
+
-
Конфигурация и управление изменениями
-
+
-
Управление рисками
+
-
-
Microsoft Solutions Framework является наиболее сбалансированной тех-
нологией, ориентированной на проектные группы малых и средних размеров.