52
Использование 6 жестких дисков обусловлено следующими сообра-
жениями:
Для достоверного функционирования операционной системы сервера
санкционирован RAID массив из 2-ух строгих дисков любой по 73 ГБ (такого
размера довольно для работы ОС). Операционная система нарочно размещена
порознь от файлов БД из мнения защищенности и производительности.
Для достоверного сбережения данных в формате Structured Query Lan-
guage (SQL) санкционирован массив строгих дисков наибольшего размера
147Гб. Предоставленного размера довольно для внедрения свежего перечня
возможностей, на данный момент размер занятого места занимает 53Гб, при
условии того собственно, что в БД сберегаться записи за 3 года.
Так же отдельно необходимо хранить данный в форматах mdf (файл
базы данных), а также транзакции в виде файлов ldf (файл транзакций), для
чего необходим еще один массив, аналогичный предыдущему по размеру.
Использование дополнительного питания повышает отказоустойчи-
вость системы. [8]
Для ПК-пользователя и ПК-инженера основными критерием выбора
оборудования в данном случае являются его технические характеристика, и
что не менее важно, соответствие утвержденным корпоративным стандартам.
Таким образом, для персональных компьютеров основным критерием выбора
является утвержденный список конфигураций ПК. (MB Asus P5 CPU:
Core2Duo 2.9Ghz Ram:2 Gb) Характеристики данной конфигурации описаны в
таблице 1.7
53
Таблица 1.7 – характеристика конфигурации ПК пользователя.
ПАРАМЕТР
ЗНАЧЕНИЕ
Корпус
Minitower IN-WIN "EMR-003", mATX, черно-серебр.
(450Вт)
Процессор
Intel "Core 2 Duo E7500" (2.93ГГц, 3МБ, 1066МГц, EM64T)
Socket775 (oem)
Кулер для про-
цессора
Socket775 Arctic Cooling "Alpine 7 GT" (ret)
Вентилятор
GlacialTech "SilentBlade II GT9225-EDLA1" d90мм,
1600об./мин. (питание от мат.платы и разъёма питания ATA
HDD) (oem)
Материнская
плата
Socket775 ASUS "P5G41-M LE/C/SI" (iG41, 2xDDR2, U100,
SATA II, PCI-E, D-Sub, DVI, SB, 1Гбит LAN, USB2.0,
mATX) (oem)
Модуль опера-
тивной памяти
2ГБ DDR2 SDRAM Kingston "ValueRAM"
KVR800D2N6/2G (PC6400, 800МГц, CL6) (ret)
Жесткий диск
320ГБ Seagate "Barracuda 7200.12 ST3320418AS"
7200об./мин., 16МБ (SATA II) (oem)
Привод
DVD±RW
24x8x16xDVD/48x32x48xCD Sony Optiarc "AD-7260S", чер-
ный (SATA) (oem)
Устройство чте-
ния карт памяти
CF/MD/SM/MMC/SD/MS/MS Pro Sony "MRW620", в 3.5"
отсек, черный (USB2.0) (oem)
54
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы Жизненного Цикла проекта автоматизации
Жизненный цикл разработки программного обеспечения (ЖЦ) - это про-
цесс, используемый индустрией программного обеспечения для проектирова-
ния, разработки и тестирования высококачественного программного обеспе-
чения. ЖЦ нацелен на производство высококачественного программного
обеспечения, которое соответствует ожиданиям клиентов или превосходит их,
в кратчайшие сроки завершает работу и оценивает затраты.
ЖЦ является аббревиатурой жизненного цикла разработки программ-
ного обеспечения.
Это также называется процессом разработки программного обеспече-
ния.
ЖЦ - это структура, определяющая задачи, выполняемые на каждом
этапе процесса разработки программного обеспечения.
ISO / IEC 12207 является международным стандартом для процессов
жизненного цикла программного обеспечения. Он призван стать стандартом,
определяющим все задачи, необходимые для разработки и обслуживания про-
граммного.
ЖЦ это процесс, которому следует программный проект в рамках орга-
низации программного обеспечения. Он состоит из подробного плана, описы-
вающего, как разрабатывать, поддерживать, заменять и изменять или улуч-
шать конкретное программное обеспечение. Жизненный цикл определяет ме-
тодологию улучшения качества программного обеспечения и общего процесса
разработки. [9]
Custom Development Method (и, методика Oracle) по разработке приклад-
ных информационных систем под заказ - конкретный материал, детализиро-
ванный до уровня заготовок проектных документов, рассчитанных на исполь-
55
зование в проектах с применением Oracle. Степень адаптивности CDM огра-
ничивается тремя моделями ЖЦ: "классическая" (предусмотрены все ра-
боты/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный под-
ход", рекомендуемый в случае малых проектов и возможности быстро прото-
типировать приложения.
RUP был разработан на основе результатов сотни различных проектов
по разработке программного обеспечения и идеи некоторых из наиболее вли-
яющих на людей в программной инженерии дисциплины. XP представляет
гибкие модели процесса. MSF была разработана на основе большого опыта
Microsoft собрала на протяжении десятилетий.
RUP, процесс доступен как продукт, становится государством-оф-прак-
тики в отрасли за последние годы и был расширен для поддержки элементов
XP.
Microsoft продвигает свою Framework решения, включив его в предсто-
ящем выпуске системы Visual Studio Team и следует примеру Rational, предо-
ставляя не только описание процесса, но и полный продукт для его поддержки.
Rational Unified Process [1] является наиболее часто используемым про-
цессом разработки программного обеспечения в промышленности. Основные
преимущества являются поддержкой через Rational Software, которая посто-
янно совершенствует процесс, поддержка инструмента и инструмент докумен-
тацию плотно соединенную, а также поддержку Rational для и наставничества
в реализации процесса. RUP обеспечивает хорошо структурированную ос-
нову, разделенную на фазы и рабочие процессы, что позволяет легкую навига-
цию в рамках. Дополнительные понятия артефактов и рабочих легко понять и
облегчить планирование ресурсов и работу структурирование. Процесс вклю-
чает в себя комплексные меры по обеспечению качества. Минимальные стан-
дарты как требования к проектированию и разработке программного обеспе-
чения итерационного включены, а также тестирования, управления конфигу-
рациями и взаимодействия с клиентом в течение всего процесса.
56
Framework Microsoft Solution [8] обеспечивает глубокое понимание раз-
работки программного обеспечения практикуются в Microsoft. MSF представ-
ляет собой попытку Microsoft, чтобы распространять свои знания по разра-
ботке программного обеспечения. MSF является одним из двух дополняющих
друг друга структур (кроме Microsoft Operations Framework (MOF)), образуя
комплексное решение для крупных софтверных компаний, занятых средних и
крупных проектов. Тем не менее, MSF может применяться самостоятельно.
Это не зависит от Министерства финансов, что позволяет легко реализации в
средних компаниях. Сосредоточение на достижение высокого качества про-
граммного обеспечения, основные принципы структуры включают в себя ите-
ративно добавлении функциональности и «по команде из-пэров» подхода без
лидера доминирующей проекта. Оба принципа не только улучшить качество
программного обеспечения, но и то, как он построен. Microsoft предоставляет
несколько шаблонов для артефактов, рекомендованных в MSF. Поскольку
MSF не включает в себя огромный набор рекомендуемых средств (которые
будут меняться с следующей версией Visual Studio), она может быть легко ин-
тегрирована в существующую среду разработки.
Экстремальное программирование [11] представляет собой совершенно
новый подход к разработке программного обеспечения. Для небольших про-
ектов, XP предлагает хороший подход для достижения высокого качества про-
граммного обеспечения. Тесное вовлечение клиента, основное внимание на те-
стировании, и подход к снижению ИКР поддержки этой цели. Тем не менее,
XP может привести к организационным проблемам при применении в боль-
ших проектах. Для большинства проектов, тесная интеграция клиента в про-
цессе разработки трудно достичь.
Основными критериями для выбора стандарта ЖЦ будут в таблице 2.1:
Итерационной – для того, чтобы установить более высокое качество
программного обеспечения, процесс разработки программного обеспечения
должен использовать итеративный и инкрементный подход к развитию. Ите-
57
рационные циклы включают все виды деятельности в области развития ана-
лиза, проектирования, реализации, тестирования и, наконец, развертывание.
Контроль качества может применяться более эффективно в течение всего про-
цесса. При использовании итеративного подхода, процесс приобретает боль-
шую гибкость при работе с изменяющимися требованиями или областью. Вы-
пуски продукта из произведения силы ранней обратной связи от клиентов и
заинтересованных сторон, которая имеет жизненно важное значение для улуч-
шения общего качества программного обеспечения. Однако, итеративная раз-
работка должна быть поддержаны управлениями рисками и ранним вовлече-
нием конечных пользователей для достижения своего полного потенциала. XP
основывается на очень строгий итеративный подходе, требующий ежеднев-
ную сборку всех компонентов. Это ограничивает время, необходимое для
столкнуться с ошибками и разработчиков сил, чтобы решить проблему как
можно скорее. Конечно, неполные компоненты или отдельные методы исклю-
чены из ежедневной сборки. Структура декомпозиции работ должна рассмот-
реть эти вопросы, чтобы позволить интеграцию мелких компонентов каждый
день. Используя этот подход требует планирования много, но, безусловно,
обеспечивает высокое качество программного обеспечения;
Качество – как цель процесс разработки программного обеспечения
необходимо определить качество как основной целью улучшения общего ка-
чества программного обеспечения. Целевые показатели качества должны быть
определены и документированы с участием команды проекта и клиента. Это
гарантирует, что цели качества становятся достижимыми и измеримыми. MSF
определяет качественные цели проекта в начале и подчеркивает выполнение
этих целей в качестве основной части проекта.
Непрерывно проверка качества – набор процедур, которые документи-
руют каждое изменение в ходе проекта необходимо, чтобы окончательно га-
рантировать качество. Не только отчеты о состоянии проекта, но и оценки те-
кущей деятельности и возможных изменений необходимы для выявления про-
58
блем, как можно скорее. Для поддержки этих процедур, каждый проект нуж-
дается в определенный процессе для управляемых изменений. Все эти дей-
ствия могут быть реализованы в виде заседаний или поддерживающих рабо-
чие процессы. Непрерывно проверки качества включает в себя тщательное те-
стирование. Кроме внутреннего тестирования, внешние приемочные испыта-
ния с клиентом необходимо также для того, чтобы убедиться, что продукт от-
вечает потребностям и требованиям заказчика. Поэтому процесс разработки
программного обеспечения должен включать в себя рабочий процесс тестиро-
вания на протяжении всего процесса, в том числе внешних испытаний с конеч-
ными пользователями, чтобы обеспечить высокое качество программного
обеспечения.
Требования к работе с клиентами – процесс разработки программного
обеспечения основывается на четкой структуре и методологии вызывать и тре-
бований заказчика документ. Он также должен интегрировать эти требования
в полном процессе. Выявление требований является одним из наиболее слож-
ного программного обеспечения инженерных дисциплин. Потребности и по-
желания клиента, которые обычно не имеют глубоких технических знаний,
должны быть документированы, так что разработчики могут создавать прило-
жения на основе этой информации. Таким образом, необходимо, чтобы ко-
манда проекта понимает клиента и его бизнеса. В противном случае это невоз-
можно правильно реализовать потребности клиентов. Процесс разработки
программного обеспечения должен сосредоточиться на требованиях на протя-
жении всего проекта. Выявление и документирование требований в начале не
является достаточным. Кроме того, процесс разработки программного обеспе-
чения должен гарантировать, что не только клиент, но и конечные пользова-
тели участвуют в процессе формирования требований. Успех проекта сильно
зависит от этих двух групп: первая покупка продукта, а второй его использо-
вания. Процесс разработки программного обеспечения должен определить
процедуры для подготовки конечных пользователей использовать конечный
продукт.
59
Архитектура привод – в современных разработках программного обес-
печения, архитектура системы оказывает значительное влияние на общем ка-
честве продукта. Одной из причин этого является интеграция в существующие
системы и окружающей среды, как большая часть сегодняшнего развития про-
граммного обеспечения. Повторное использование приобретает все большее
значение в связи с увеличением времени и давления затрат.
Фокус на команды – команда должна рассматриваться как совокупность
равноправных лиц, которые вместе несут ответственность за качество и
успешность проекта. Когда ответственность за неудачи может быть отнесена
к одному человеку, успех проекта не гарантирован больше. Сосредоточение
на совместную работу и повышает мотивацию участников проекта, так как все
это рассматривается как столь же важной частью проекта. Это в конечном
итоге приводит к высокой идентификации членов команды с продуктом. Оче-
видно, что мотивированные члены команды способствуют высокому качеству,
поскольку они работают более концентрированными и добросовестными.
Процесс разработки программного обеспечения должна включать четко опре-
деленную структуру команды, в том числе эффективной постановки задач и
четких руководящих принципов коммуникации. MSF «команда сверстников»
присваивает значение равного по каждому члену команды и роли: полная ко-
манда имеет шесть целей для достижения и может рассматриваться как мощ-
ные реализации принципа команды фокуса. В большинстве проектов некото-
рые цели имеют более высокое значение, чем другие. Менеджеры решают са-
мостоятельно или возложить ответственность за неспособность членов своей
команды. MSF «команда коллег» концепция позволяет избежать этих проблем
и позволяет проект, чтобы получить прибыль от всех возможностей коллек-
тивной работы.
Парное программирование – парное программирование тесно связано с
акцентом на команды, но был выбран в качестве другого критерия оценки, по-
скольку он был недооценен за свой вклад в высокое качество в прошлом. XP
60
демонстрирует, как два разработчики могут дополнять друг друга, а не инги-
бирования друг друга. Один разработчик реализует текущий метод, а другой
работает над вопросами интеграции. Такой подход экономит время и миними-
зирует количество ошибок. Лучшие решения, более вероятно, так как два че-
ловека, скорее всего, имеют разные точки зрения той же проблемы и, следова-
тельно, дополняют друг друга в ее решении.
Портняжное с ограничениями – процесс разработки программного обес-
печения должен быть определен и формализован в пути относительно его при-
менения к широкому набору проектов. Процесс, который концентрируется на
небольшой или специализированный наборе проектов гарантирует высокое
качество в конкретной среде. Основной целью процесса является применение
многих проектов внутри компании, не снижая его прочности. Процесс должен
быть адаптирован к различным проектам на основе ее основные элементы. Для
того, чтобы охватить всю сложность типовых проектов заданного набора ос-
новных элементов должно быть сохранено. Большое количество основных
элементов, не обязательно улучшить качество конечного продукта. Поэтому
процесс разработки программного обеспечения должны опираться на основ-
ные элементы. Основываясь на этих основных элементах, процесс должен
определить методы для пошива процесса к типу проекта и размера проекта.
Конфигурация и управление изменениями – хорошо функционирующая
конфигурация и управление изменениями (КЗУ) является важной частью обес-
печения качества программного обеспечения. Существование или не суще-
ствование КЗУ оказывает наибольшее влияние при обслуживании программ-
ного обеспечения и развития, все же основы для КЗУ (надлежащей докумен-
тации, кода архивов источника и т.д.) должны быть установлены в процессе
разработки.
Управление рисками – корректное понимание риска и форма управления
смягчением вместе эффективное управление рисками и является ключевым
фактором в достижении высокого качества продукции. Управление рисками
61
позволяет смягчить риск раннего и возможность действовать вместо реагиро-
вать на проблемы и риски. MSF представляет свою собственную модель
управления рисками. Она, следовательно, делает акцент на дисциплине как
важное значение для поддержания проекта на трассе улучшая общее качество
доставки. Управление рисков как собственная дисциплина является критерием
для любого процесса разработки программного обеспечения с акцентом на
улучшении качества программного продукта. Управление рисками в рамках
ежедневных встреч и других дисциплин предполагает, что идентификация и
управление рисками становится менее важным, поскольку проектная группа
занята другими проблемами. Проект становится восприимчивым к факторам
риска.
Таблица 2.1 – Критерии для выбора стандарта
Критерий
MSF
RUP
XP
Разработка программного обеспечения
Итерационной
+
+
+
Качество как цель
+
-
-
Непрерывно проверка качества
+
+
+
Требования заказчика
+
+
+
Архитектура привод
+
+
+
Фокус на команды
+
+
+
Парное программирование
+
-
-
Портняжное с ограничениями
+
+
-
Конфигурация и управление изменениями
+
-
-
Управление рисками
+
-
-
Microsoft Solutions Framework является наиболее сбалансированной тех-
нологией, ориентированной на проектные группы малых и средних размеров.
MSF не накладывает никаких ограничений на используемый инструментарий