Дипломная работа: Исследование и разработка информационной системы учета сбыта продукции на примере ТОО "GT MACHINERY"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
60
«Внедрение»;
Трудоемкость разработки системы зависит от степени новизны разработки,
сложности алгоритма её функционирования, объема используемой информации и
виде её обработки, уровня используемого алгоритмического языка
программирования.
По степени новизны разрабатываемая система относится к группе «б»
(разработка программной продукции, имеющей аналоги). По степени сложности
алгоритма функционирования системы относится к 3-ей группе (программная
продукция, реализующая алгоритмы стандартных методов решения задач). [9]
Модель жизненного цикла представляет собой структуру, состоящую из
процессов, действий и задач, которые реализуются при разработке,
функционировании и сопровождении программного продукта в продолжение
всей жизни системы, от установления требований до завершения ее применения.
Имеется ряд моделей и стандартов, в определенной мере направленных на
регламентирование жизненного цикла, многие из них принадлежат к заказному
ПО (автоматизированным системам АС, и др.) и помимо непосредственно ЖЦ
регламентируют также и процессы разработки:
ГОСТ 34.601-90 касается автоматизированных систем и определяет стадии
и этапы их создания. К тому же, стандарт содержит описание содержания работ
на всех этапах. Стадии и этапы работы, которые закреплены в стандарте, в
большей мере подходят под каскадную модель жизненного цикла;
ISO/IEC 12207:1995 стандарт касается процессов и организации
жизненного цикла. Затрагивает все виды заказного ПО. В стандарте не
содержится описание фаз, стадий и этапов;
CustomDevelopmentMethod (и, методика Oracle) по разработке прикладных
информационных систем под заказ – является конкретным материалом,
детализированным до уровня заготовок проектных документов, которые
рассчитаны на применение в проектах с использованием Oracle. Степень
адаптивности CDM ограничивают три модели ЖЦ: "классическая"
(предусматриваются все работы/задачи и этапы), "быстрая разработка"
(FastTrack), "облегченный подход", который рекомендуется в малых проектах и
при возможности быстрого прототипирования приложения;
61
RationalUnifiedProcess (RUP) предлагает итеративную модель разработки,
состоящую из четырех фаз: начала, исследования, построения и внедрения.
Каждую фазу можно разбить на этапы (итерации), в результате которых
происходит выпуск версии для внутреннего или внешнего применения.
Прохождение через четыре главные фазы обозначают как цикл разработки,
каждый цикл завершает генерация версии системы. Если после этого работа над
проектом не завершается, то развитие полученного продукта продолжается, и он
снова проходит те же фазы. Суть работы в рамках RUP - это создавать и
сопровождать модели, а не бумажные документы. Поэтому данный процесс
привязан к пользованию конкретными средствами моделирования (UML), а также
конкретной технологией проектирования и разработки (объектно-
ориентированный анализ, object-orientedanalysis (OOA), объектно-
ориентированное программирование, object-orientedprogramming(OOP);
MicrosoftSolutionFramework (MSF) сходна с RUP, также состоит из четырех
фаз: анализа, проектирования, разработки, стабилизации, считается
итерационной, предполагает пользование объектно-ориентированным
моделированием. MSF, если сравнивать с RUP, в большей мере ориентирована на
разработку бизнес-приложений.
Основные критерии для выбора стандарта ЖЦ представлены:
актуальностью и современностью применяемых методик контроля
разработки;
разработкой в итерационном режиме с возможностью осуществлять
контроль рисков и выполнять сам проект на неких контрольных точках,
отсутствием дополнительных требований по моделированию процесса
разработки и внедрения.
Резюмируя описание стандартов выше, отметим, что итерационными из
них считаются 4 стандарта: MSF, RUP, COBIT, XP.
Стандарт COBIT не подходит, так как основная цель его применения – это
проведение аудита и стратегического планирования ИС и IT инфраструктуры в
целом.
62
Стандарт XP не подходит, поскольку в нем не содержатся полноценные
этапы ЖЦ, представленные выработкой концепции, планированием, разработкой,
стабилизацией, внедрением.
Соответственно, необходимо выбрать RUP или MSF. Оба стандарта
молодые и поддерживают все новые технологии продуктивной разработки и
контроля их выполнения.
RationalUnifiedProcess (RUP) представляет собой хорошо
сбалансированное решение для средних по размерам коллективов разработчиков,
которые работают с использованием продуктов и технологий компании Rational.
Сопровождение разработки системы и самой системы регламентирует
методология RUP, но все же эта технология весьма сильно ориентирована на
внутрифирменные инструментальные средства.
ExtremeProgramming хорошо подходит для проектных групп, имеющих
малый размер, и для небольших систем, в которых часто изменяются требования.
Ключевая проблема XP выражена сопровождением. Если имеет место
текучка кадров в коллективе разработчиков, то значительную часть проектной
информации можно потерять вследствие практически отсутствующей
документации. [10]
MicrosoftSolutionsFramework представляет собой наиболее
сбалансированную технологию, ориентированную на проектные группы,
имеющие малые и средние размеры. MSF не накладывает никаких ограничений
на применяемый инструментарий и содержит довольно общие рекомендации.
Однако этими рекомендациями можно воспользоваться, чтобы построить
конкретный процесс, соответствующий потребностям коллектива разработчиков.
Помимо этого, основное преимущество MSF представлено итерационной
моделью одновременно с уточняющими вехами (аналог каскадной модели). Итак,
в реализации MSF сделана попытка объединения каскадной и итерационной
модели разработки и внедрения ПО.
Исходя из описанных выше преимуществ, мы выбрали стандарт MSF как
самый гибкий и удобный для осуществления АИС.
63
Одно из преимуществ выбранного стандарта представлено возможностью
управления одновременно и проектом разработки приложения и внедрением
инфраструктуры.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Поскольку весь ЖЦ проекта разделён на этапы, каждый этап обладает
ролями, за которыми закреплены цели, которые следует достигнуть, и всё же на
каждой фазе имеются некоторые риски.
В фазе выработки концепции возможно возникновение следующих рисков:
недальновидный анализ сроков проекта и его бюджета. Чтобы
ликвидировать такой риск, необходимо более детально прорабатывать задачи и
цели проекта, устанавливать больше контрольных точек;
неправильно подобранный проектный состав исполнителей может
привести к полному отсутствию командной работы. Для уменьшения данного
риска более тщательно подбирают специалистов в проектную группу, тестируя не
только профессиональные навыки, но и личностные качества.
На фазе планирования возможно возникновение следующих рисков:
неверно или не совсем корректно сформированная архитектура
выбираемого решения. На возможность возникновения данного риска влияет
компетенция руководителя проекта, который должен принять решение о выборе
архитектуры разрабатываемого решения.
В фазе разработки возможно возникновение следующих рисков:
неправильная интерпретация технического задания и как результат
неправильное программирование архитектуры и сдвиг сроков. Чтобы
минимизировать данный риск, нужно более чётко написать техническое задание,
понятное для программиста;
еще один немаловажный риск в этом проекте представлен
отсутствием необходимой квалификации у программиста в том языке, на котором
решено реализовывать программу, которая будет распределять заявки между
инженерами.
В случае если программист не будет успевать в заданное время
календарного плана проекта, придется воспользоваться внешним разработчиком,
так называемым “аутсорсингом” или “фрилансом”.
64
В фазе тестирования возможно возникновение следующих рисков:
риски неоконченного тестирования. Возможна ситуация, когда
программный продукт будет протестирован не до конца. При этом необходимо
провести повторное тестирование на следующей итерации разработки.
В фазе внедрения возможно возникновение следующих рисков:
риски неправильного принятия решения о законченности части
проекта. Данные риски приводят к проблеме незаконченности решения и
возможности появления нестыковок с другими частями разрабатываемой ИС. Для
устранения необходимо доработать при следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализации
информационной безопасности.
Защита от внутренних угроз. Подразумевает разграничение прав
пользователей. Подробные права пользователей описаны в таблице 6.
Источник: https://baza.diplomsite.ru/previewfile/8737