Дипломная работа: Автоматизация "личного кабинета" консультанта по недвижи-мости компании СТРОИТЕЛЬНОЕ УПРАВЛЕНИЕ «МОСГОРТРАНССТРОЙ» ГУП «МОСГОРТРАНС»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
31
Существует ряд требований к рабочим местам пользователей, реализация которых
существенно повысит быстродействие системы в целом.
Для функционирования разрабатываемой ИС была выбрана следующая конфигура-
ция персональных компьютеров для клиентов:
− процессор – Intel core 2 duo 2.2 GHz;
− память - от 4 Gb;
− жесткий диск от 200 Gb;
− CD-ROM - от 48x;
− Монитор - 19” Samsung SyncMaster;
− принтер HP LaserJet 1100;
− клавиатура и мышь Genius.;
− операционная система – Windows 7/8/8.1;
− сервер СУБД - SQL Server Management Studio Express;
− наличие средств информационной безопасности данных.
В качестве активного оборудования ЛВС используется управляемый
коммутатор 2-го уровня DES-1210-28 фирмы D-Link.
Коммутатор поддерживает полнодуплексный режим передачи данных и ори-
ентирован на применение в топологии «звезда».
Серия коммутаторов D-Link DES-1210 включает в себя модернизированные
коммутаторы семейства Web Snnart, объединяющие функции расширенного управ-
ления и безопасности, хорошую масштабируемость и производительность.
Модель DES-1210-28 поддерживает функцию Auto Voice VLAN, позволяю-
щую устанавливать первоочередной приоритет для пакетов голосовой связи и
обеспечивать бесперебойную работу приложения VoIP (передача голоса по сети),
автоматическое определение NNDI/NNDIX, что исключает проблему применения
кроссированных кабелей либо портов UpLink и делает подключение коммутатора
весьма необременительным.
Расширение стандартных функций 2-го уровня включает в себя IGNNP
Snooping, Spanning Tree (алгоритм отставного дерева), Port NNirroring и Link
Aggregation Control Protocol (LACP), а управление потоком IEEE 802.3x позволяет
напрямую подключить коммутатор к серверу для быстрой и надежной передачи
данных.
32
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл - это непрерывный процесс, который начинается с момента
принятия решения о необходимости его создания и заканчивается в момент его
полного изъятия из эксплуатации. Среди наиболее известных стандартов можно
выделить следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные системы и уста-
навливает стадии и этапы их создания. Кроме того, в стандарте содержится описа-
ние содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в
стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207 - стандарт на процессы и организацию жизненного цикла.
Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз,
стадий и этапов.
Custom Development Method (методика Orаcle) по разработке прикладных
информационных систем - технологический материал, детализированный до уров-
ня заготовок проектных документов, рассчитанных на использование в проектах с
применением Orаcle. Применяется CDM для классической модели ЖЦ (предусмот-
рены все работы/задачи и этапы), а также для технологий "быстрой разработки"
(Fаst Trаck) или "облегченного подхода", рекомендуемых в случае малых проектов.
Rаtionаl Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение. Каждая
фаза может быть разбита на этапы (итерации), в результате которых выпускается
версия для внутреннего или внешнего использования. Прохождение через четыре
основные фазы называется циклом разработки, каждый цикл завершается генера-
цией версии системы. Если после этого работа над проектом не прекращается, то
полученный продукт продолжает развиваться и снова минует те же фазы. Суть ра-
боты в рамках RUP - это создание и сопровождение моделей на базе UML .
Microsoft Solution Frаmework (MSF) сходна с RUP, так же включает четыре
фазы: анализ, проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. MSF в
33
сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений.
Extreme Progrаmming (XP). Экстремальное программирование (самая новая
среди рассматриваемых методологий) сформировалось в 1996 году. В основе мето-
дологии командная работа, эффективная коммуникация между заказчиком и ис-
полнителем в течение всего проекта по разработке ИС, а разработка ведется с ис-
пользованием последовательно дорабатываемых прототипов.[15]
При выборе стандарта основным определяющим фактором является более
полное и подробное описание работ на стадиях и этапах разработки
АС(автоматизируемых систем). Стандарт ISO/IEC 12207 не содержит подробное
описание работ на разных стадиях и этапах разработки АС. Стандарт CDM рассчи-
тан на использование в проектах с применением Orаcle технологий, который в дан-
ном проекте не используются. Стандарт MSF, как было ранее сказано, в большей
степени ориентирован на разработку бизнес-приложений. Стандарт XP ориентиро-
ван на командную работу. В данном проекте будет использоваться ГОСТ 34.601-
90, так как он содержит описание работ на каждом этапе разработки АС.
Далее произведем выбор стратегии внедрения разработанной системы. В
настоящий момент выделяется четыре стратегии внедрения информационной си-
стемы:
• Параллельная стратегия - для случая, когда старую работающую систему
необходимо заменить новой;
• Скачок – эта стратегия подразумевает резкий переход от одной системы ав-
томатизации к другой;
• Опытная эксплуатация "пилотного проекта - это тактика "скачка", но приме-
няемая к ограниченному числу изделий, наиболее успешна в малом участке
деятельности;
• Узкое место - при внедрении "узкого места" план внедрения выполняется
только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также особенно-
стей разрабатываемой информационной системы, в качестве стратегии внедрения
была выбрана стратегия Опытная эксплуатация пилотного проекта, так как в этом
случае внедрение системы произойдет наиболее безболезненно.
34
Для проекта разработки АРМ личного кабинета консультанта по недвижи-
мости наиболее подойдет каскадная модель для разработки приложения из-за воз-
можности контроля промежуточных фаз.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Любой сложный проект, а особенно проект разработки программного обес-
печения, содержит в себе много неопределенных моментов, которые влекут за со-
бой риски реализации проекта [10].
Управление рисками заключается в их раннем выявлении и разработке мер,
либо полностью предотвращающих их возникновение, либо минимизирующих их
последствия.
В настоящее время существует три общепринятых стратегии управления
рисками:
− Избегание рисков – проект реорганизуется таким образом, чтобы исключить
возможность возникновения рисков;
− Делегирование рисков – проект реорганизуется таким образом, чтобы пере-
ложить риски на третью сторону (заказчика, банки, вендора и т.п.);
− Принятие рисков – риски признаются в качестве неизбежной составляющей
проекта, проводится постоянный мониторинг симптомов их наступления, по-
стоянно корректируется план действий в случае наступления рисков [11].
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а опосредо-
ванные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
1. Ресурсные риски:
− организация (выполняла ли организация прежде проекты такого масштаба,
существует ли формальный процесс разработки программного обеспечения и
т.п.);
− финансирование (полностью ли обеспечено финансирование проекта, фикси-
рована ли стоимость проекта или она является предметом для обсуждения,
точно ли выполнена оценка затрат и т.п.);
− люди (достаточно ли людей для выполнения проекта, обладают ли они необ-
ходимыми навыками и опытом, работали ли они вместе раньше и т.п.);
35
− время (реалистичен ли план проекта, насколько критичной является дата
окончания проекта и т.п.);
− бизнес (что произойдет, если конкурент выйдет на рынок первым, выгода, по-
лученная от реализации проекта больше, чем затраты на него, что произойдет,
если ключевые поставщики не смогут выполнить свои обязательства и т.п.).
2. Технические риски:
− область действия (scope) проекта (могут ли быть измерены критерии успеш-
ного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
− технологии (отлажена ли применяемая технология или она только была раз-
работана, и т.п.) [12];
− внешние зависимости (зависит ли проект от других параллельных проектов,
зависит ли успех проекта от внешних поставщиков технологий и/или продук-
тов и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 8).
Таблица №8
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного бюд-
жета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия
в проекте
Заказ
Неформализуемая задача (невоз-
можно автоматизировать те или
иные бизнес-процессы или стои-
мость такой автоматизации превы-
сит ожидаемую выгоду)
Пересмотреть область дей-
ствия проекта с целью выде-
ления отдельных задач, под-
дающихся автоматизации.
Провести детальный анализ
бизнес-процессов и предло-
жить комплекс мероприятий
по их реорганизации.
Источник: https://baza.diplomsite.ru/previewfile/2503