Основные способы построения ИС
Существует несколько способов построения ИС (но основных 4):
1. Разработка системы «под себя»
2. Использование прототипов – вместо полной системы создается прототип, отвечающий основным потребностям пользователей.
1) определение основных запросов
2) создание рабочего прототипа
3) использование рабочего прототипа
4) пересмотр и улучшение прототипа
5) работа с окончательной версией прототипа
3. Использование готовых решений – рекомендуется в максимальной степени использовать стандартные технологии и автоматизации бизнеса.
4. Использование услуг сторонней организации для передачи функций управления ИС – организация использует специализированную фирму, которая выполняет управляющие функции по функционированию и развитию ИС компании.
· гарантийное качество обслуживания
· экономия денежных средств
· потеря контроля за ИТ
ПРОСТЫЕ МОДЕЛИ ПРОЦЕССА СОЗДАНИЯ СИСТЕМ
Общие понятия
Процесс создания программного обеспечения — это множество взаимосвязанных процессов и результатов их выполнения, которые ведут к созданию программного продукта. Процесс создания ПО может начинаться с разработки программной системы «с нуля», но чаще новое ПО разрабатывается на основе существующих программных систем путем их модификации.
Процесс создания ПО, как и любая другая интеллектуальная деятельность, основан на человеческих суждениях и умозаключениях, т.е. является творческим. Несмотря на то что наблюдается огромное многообразие подходов, методов и технологий создания ПО, существуют фундаментальные базовые процессы, без реализации которых не может обойтись ни одна технология разработки программных продуктов. Перечислим эти процессы.
1. Разработка спецификации ПО. Это фундамент любой программной системы. Спецификация определяет все функции и действия, которые будет выполнять разрабатываемая система.
2. Проектирование и реализация (производство) ПО. Это процесс непосредственного создания ПО на основе спецификации.
3. Аттестация ПО. Разработанное программное обеспечение должно быть аттестовано на соответствие требованиям заказчика.
4. Эволюция ПО. Любые программные системы должны модифицироваться в соответствии с изменениями требований заказчика.
Модель процесса создания программного обеспечения — это общее абстрактное представление данного процесса. Каждая такая модель представляет процесс создания ПО в каком-то своем «разрезе», используя только определенную часть всей информации о процессе. В настоящем разделе представлены обобщенные модели, основанные на архитектурном подходе. В этом случае можно увидеть всю структуру процесса создания ПО, абстрагируясь от частных деталей отдельных составляющих его этапов.
Эти обобщенные модели не содержат точного описания всех стадий процесса создания ПО. Напротив, они являются полезными абстракциями, помогающими «приложить» различные подходы и технологии к процессу разработки. Кроме того, очевидно, что процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы.
В этой главе рассматриваются следующие модели создания программного обеспечения.
1. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса.
2. Эволюционная модель разработки ПО. Здесь последовательно перемежаются этапы формирования требований, разработки ПО и его аттестации. Первоначальная программная система быстро разрабатывается на основе некоторых абстрактных общих требований. Затем они уточняются и детализируются в соответствии с требованиями заказчика. Далее система дорабатывается и аттестуется в соответствии с новыми уточненными требованиями.
3. Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонентов также выполняется математическими методами.
4. Модель разработки ПО на основе ранее созданных компонентов. Предполагает, что отдельные составные части программной системы уже существуют, т.е. созданы ранее. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонентов в общее целое, а не их созданию.
Каскадная и эволюционная модели разработки широко используются на практике. Модель формальной разработки систем успешно применялась во многих проектах, но количество организаций-разработчиков, постоянно использующих этот метод, невелико. Использование готовых системных компонентов практикуется повсеместно, но большинство организаций не придерживаются в точности модели разработки ПО на основе ранее созданных компонентов. Вместе с тем этот метод должен получить широкое распространение в XXI столетии, поскольку сборка систем из готовых или ранее использованных компонентов значительно ускоряет разработку ПО.
Каскадная модель
Это первая модель процесса создания ПО, порожденная моделями других инженерных процессов. Она показана на рис. 1. Эту модель также иногда называют моделью жизненного цикла программного обеспечения.
Жизненный цикл программного обеспечения — это совокупность процессов, протекающих в период от момента принятия решения о создании ПО до его полного вывода из эксплуатации. Таким образом, «жизненный цикл ПО является более широким понятием, чем модель процесса создания ПО. Вместе с тем каскадную модель можно рассматривать как одну из моделей жизненного цикла ПО.
Основные принципиальные этапы (стадии) этой модели отражают все базовые виды деятельности, необходимые для создания ПО.
1. Анализ и формирование требований. Путем консультаций с заказчиком ПО определяются функциональные возможности, ограничения и цели создаваемой программной системы.
2. Проектирование системы и программного обеспечения. Процесс проектирования системы разбивает системные требования на требования, предъявляемые к аппаратным средствам, и требования к программному обеспечению системы. Разрабатывается общая архитектура системы. Проектирование ПО предполагает определение и описание основных программных компонентов и их взаимосвязей.
3. Кодирование и тестирование программных модулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям к данному модулю.
4. Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной системы. Проверяется, соответствует ли система своей спецификации.
5. Эксплуатация и сопровождение системы. Обычно (хотя и не всегда) это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и начинается период ее эксплуатации. Сопровождение системы включает исправление ошибок, которые не были обнаружены на более ранних этапах жизненного цикла, совершенствование системных компонентов и «подгонку» функциональных возможностей системы к новым требованиям.
Рис. 1. Жизненный цикл программного обеспечения
В принципе результат каждого этапа должен утверждаться документально (это как бы сигнал об окончании этапа). Тогда следующий этап не может начаться до завершения предыдущего. Однако на практике этапы могут перекрываться с постоянным перетеканием информации от одного этапа к другому. Например, на этапе проектирования может возникнуть необходимость уточнить системные требования либо на этапе кодирования могут выявиться проблемы, которые можно решить лишь на этапе проектирования, и т.д. Процесс создания ПО нельзя описать простой линейной моделью, так как он неизбежно содержит последовательность повторяющихся процессов.
Поскольку на каждом этапе проводятся определенные работы и оформляется сопутствующая документация, повторение этапов приводит к повторным работам и значительным расходам. Поэтому после небольшого числа повторений обычно «замораживается» часть этапов создания ПО, например этап определения требований, но продолжается выполнение последующих этапов. Возникающие проблемы, решение которых требует возврата к «замороженным» этапам, игнорируются либо делаются попытки решить их программно. «Замораживание» этапа определения требований может привести к тому, что разработанная система не будет удовлетворять всем требованиям заказчика. Это также может привести к появлению плохо структурированной системы, если упущения этапа проектирования исправляются только с помощью программистских хитростей.
Последний этап жизненного цикла ПО (эксплуатация и сопровождение) — это «полноценное» использование программной системы. На этом этапе могут обнаружиться ошибки, допущенные, например, на первом этапе формирования требований. Могут также проявиться ошибки проектирования и кодирования, что может потребовать определения новых функциональных возможностей системы. С другой стороны, система постоянно должна оставаться работоспособной. Внесение необходимых изменений в программную систему может потребовать повторения некоторых или даже всех этапов процесса создания ПО.
К недостаткам каскадной модели можно отнести негибкое разбиение процесса создания ПО на отдельные фиксированные этапы. В этой модели определяющие систему решения принимаются на ранних этапах и затем их трудно отменить или изменить, особенно это относится к формированию системных требований. Поэтому каскадная модель применяется тогда, когда требования формализованы достаточно четко и корректно. Вместе с тем каскадная модель хорошо отражает практику создания ПО. Технологии создания ПО, основанные на данной модели, используются повсеместно, в частности для разработки систем, входящих в состав больших инженерных проектов.
Дата добавления: 2016-01-26 ; просмотров: 1853 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Источник
Способы построения информационной системы
Фазы проектирования и разработки информационной системы в рамках ее жизненного цикла могут быть сведены к четырем возможным путям построения информационной системы. Разработка системы.
Этот способ означает создание системы «под себя» собственными силами или посторонними специалистами.
Стадии разработки: инициирование проекта;
анализ потребностей (изучение документов и документооборота, интервью, анкетирование, составление обзоров);
техническая работа (дизайн, программирование модулей, интегрирование, тестирование); контроль;
внедрение (конверсия данных, обучение персонала и пользователей, разработка документации, исправление ошибок и т.п.); эксплуатация.
Сложности самостоятельной разработки информационной системы обычно связывают с крупным масштабом организации, соответственно с
многочисленностью и разнообразием пользователей, с большим числом и разнообразием данных, с географически распределенной организацией и т. п. Такой подход к созданию информационной системы обычно требует значительных затрат ресурсов и времени, плохо адаптируется к изменениям в организации. Использование прототипов.
В данном случае вместо полноценной системы с помощью специальных средств создается ее прототип (подразделениями заказчика или сторонней организацией), отвечающий основным потребностям пользователей. Этот прототип, построенный из стандартных элементов, но за малое время, будет относительно недорогим. Этапы его разработки: определение основных запросов; создание рабочего прототипа;
использование рабочего прототипа (оценка прототипа, уточнение потребностей);
пересмотр и улучшение прототипа;
работа с окончательной версией прототипа.
При применении прототипов пользователи играют более активную роль в развитии системы, тратится меньше времени и усилий на ее создание, внедрение осуществляется легче, так как пользователь знает, чего ожидать, и т.д.
Возможность такого подхода связана с наличием у организаций общих и уникальных черт. Использование общности черт и задач позволяет привязать готовые решения (модели и программы) к условиям конкретного пользователя и его задачам. Например, большинство организаций решает типовые задачи в бухгалтерском учете, финансах, организации управленческого труда, автоматизации документооборота, создании информационно-справочных систем, управлении кадрами и т. п. В рамках таких задач выбор типовых решений будет оправданным и эффективным. Особенно это касается малого бизнеса.
Для создания информационной системы рекомендуется в максимальной степени использовать стандартные технологии автоматизации бизнеса:
информационные технологии «клиент—сервер» в корпоративном
документообороте и деловых операциях;
управления электронными документами;
проектирования, моделирования и анализа сложных информационных систем;
финансово-экономического анализа деятельности;
систем поддержки принятия решений и др.
Покупка готового решения означает, что организация выбирает на рынке готовую информационную систему, разработанную специализированной фирмой, и внедряет ее у себя (рис. 2.3).
Рынок информационных систем включает в себя «готовые решения» от простых финансово-учетных систем (автоматизирующих отдельные функции управления), реализованных в виде пакета программ, ориентированных на малый
бизнес, до средних и крупных интегрированных информационных систем. Методы выбора поставщика «готового решения» описаны в [4].
Для примера приведем названия возможных сегментов такого рынка: структурированные кабельные системы; активное оборудование; телекоммуникационный рынок;
серверы, персональные компьютеры, сетевые компьютеры, кластеры, распределенные вычисления;
гибкие производственные системы; операционные системы; базы данных;
системы групповой работы; почтовые системы; системы подготовки документов; системы поддержки продаж;
системы автоматизации деятельности по управлению проектами;
консалтинг в области информационных технологий;
автоматизация деятельности предприятий;
методы и средства разработки систем программного обеспечения;
обучение информационным технологиям;
предоставление услуг по выполнению функций информационной системы (аутсорсинг).
Положительные стороны использования готовых решений: наличие сопровождения системы разработчиком;
тщательное тестирование предлагаемой системы разработчиком, быстрое выявление ошибок с помощью большого круга пользователей; качественное документирование системы;
периодические улучшения или усовершенствования системы разработчиком;
возможность сосредоточить ресурсы организации на поддержке работы системы, а не на разработке, и др. Использование услуг посторонней организации для передачи ей функций информационной системы.
В этом случае организация использует специализированную фирму, с помощью собственных ресурсов выполняющую действия, которые должна была осуществлять информационная система организации. Это означает, что организация не создает у себя информационных подразделений, возможно, что и аппаратнопрограммные средства будут находиться в собственности специализированной фирмы. И вся информация обрабатывается этой фирмой, а организация получает итоговую информацию с заданной периодичностью.
Таким образом, в данном случае выполнение проектов информационной системы и услуг по поддержке аппаратно-программных средств, а также дальнейшую модернизацию системы берет на себя специализированная организация. Преимущества использования внешних ресурсов: экономия и освобождение денежных средств; гарантия определенного качества обслуживания; предсказуемость результатов; гибкость системы информационного обеспечения; освобождение человеческих ресурсов для других проектов.
Недостатки такого информационного обеспечения: потеря контроля над информационными технологиями; зависимость от специализированной фирмы; необходимость делиться конфиденциальной информацией и др.
Источник
