технология проектирования ИС. Реферат на тему _Технологии проектирования ИС_. Лекция Технологии проектирования ис 1 Основные определения
 Скачать 0.49 Mb.
|
|
3.1.1. Причины изменения ИС в организациях Компании обычно меняют свои ИС по одной из следующих причин. Измененияе потребностей пользователей или предприятия. Увеличение конкуренции, рост предприятия или объединение с другими, новые законы, изменения в локальных, региональных или глобальных взаимоотношениях могут изменить структуру и намерения организации. Чтобы соответствовать новым требованиям, ИС должна тоже измениться. Изменение технологии. По мере того как технологии развиваются и становятся более дешевыми, у организации появляется возможность иметь систему, более отвечающую ее нуждам. Улучшение деловых процессов. Многие компании устанавливают новые ИС, стремясь повысить эффективность своей деятельности. Например, сократить время ожидания клиентов. Получение преимуществ в конкурентной борьбе. Улучшение качества, увеличение количества и скорости выработки информации может привести к улучшениям в продукте или услуге или помочь сократить затраты. Прирост производительности. Компьютеры автоматизируют многие канцелярские и рутинные работы. Экспертные системы дают многим людям доступ к знаниям экспертов. Рост. Растущие компании нуждаются либо в переделке, либо в замене своих ИС. Сокращение. Часто компании переходят от централизованных систем с большими ЭВМ к ПК, работающим в сети, чтобы получить преимущество в отношении це- на/производительность. Улучшение качества. Трудно улучшить качество продуктов и услуг без улучшений в системе, от которой компании получают данные, измеряющие и оценивающие качество. Чтобы что-то менять, надо знать, что именно имеет недостаточное качество. 3.1.2. Принципы разработки системы Привлечь владельца и пользователей к процессу разработки. Этот принцип обязательно следует выполнять для успешной разработки системы. Лица, ответственные за разработку системы, должны уделять время владельцу и пользователям, настаивая на их участии в согласовании всех решений, с ними связанных. Поэтому методологии уменьшают риск, связанный с сокращением функциональности системы и ошибками. Использовать подход, направленный на разрешение проблем. Методология является подходом к построению систем на основе разрешения проблем. Классический подход к проблемной ориентации описывается следующим образом: • изучается и понимается проблема и содержание системы; • определяются требования приемлемого решения; • определяются варианты решений и выбирается лучшее; • проектируется и применяется решение; • наблюдаются и оцениваются воздействие решений и соответствующим образом усовершенствуются решения. Среди начинающих разработчиков систем имеется тенденция игнорировать или сокращать этапы решения проблемы, что приводит к неадекватному пониманию и решению задач. Установить этапы и виды деятельности. Большинство методологий состоят из этапов. В классическом виде жизненный цикл состоит из четырех этапов: обзор системы, анализ системы, проектирование системы, применение системы. Пятый этап - поддержка системы усовершенствует полученную систему, повторяя предыщушие четыре этапа в меньшем объеме с целью улучшения и усовершенств ования системы. Этапы обычно делятся на действия и задачи, которые легче управляются и выполняются. Установить стандарты для согласования разработки и документации. Стандарты разработки системы обычно описывают: • виды работ; • ответственности; • руководство или требования по документированию; • проверку качества. Рассматривать систему как инвестиционный проект. Действительно, система представляет собой инвестирование средств. Когда рассматриваются направления инвестирования, выбор следует делать на основе выполнения анализа стоимость- эффективность нескольких возможных вариантов решения проблемы. Стоимость эффективность определяется как результат, полученный вычислением баланса между стоимостью разработки и функционирования системы и выгоды, полученной от системы. Не следует пренебрегать пересмотром масштаба системы. Значительным преимуществом поэтапного подхода разработки системы является возможность пересматривать технико-экономическое обоснование. При длительных разработках своевременное прекращение проекта менее убыточно, нежели продолжение разработки и применение системы, не обеспечивающей необходимый уровень эффекта от внедрения. Большинству аналитиков не удается выдержать запланированную стоимость и график выполнения работ в случае увеличения масштаба системы. В результате аналитики часто и без необходимости принимают на себя ответственность по превышению стоимости и корректировке графика работ. В методологию процесса разработки встраиваются контрольные точки, в которых стоимость сравнивается с некоторой величиной, представляющей стоимостную границу возможного продолжения разработки. В каждой контрольной точке следует принимать решение о прекращении работ, пересмотре стоимости и графика работ, частичном сокращении масштаба системы или выделении дополнительных средств. Разделяй и властвуй. Все системы являются частью больших систем, называемых суперсистемами. С другой стороны, любая система может рассматриваться состоящей из меньших частей, называемых подсистемами. В процессе разработки система разбивается (декомпозируется) на подсистемы с целью упрощения изучения декомпозированных проблем. В результате декомпозиции большой проблемы (системы) на более мелкие части (подсистемы) появляется возможность упростить процесс анализа и решения проблем. Проектировать систему с учетом ее развития и изменений. Многие системные аналитики рассматривают только требования сегодняшнего дня в процессе разработки системы. "Энтропия" - термин, используемый учеными для описания естественного и неизбежного процесса распада всех систем. Таким образом, в процессе поддержки неизбежно наступает момент, когда эксплуатационные затраты на поддержку системы превосходят стоимость разработки новой или усов ершенствования действующей системы, и на смену устаревшей системы следует разрабатывать новую систему. Системы, которые разрабатываются только с учетом требований сегодняшнего дня. трудно поддаются модификации в ответ на вновь возникающие требования системы. Современные инструментальные и технологические средства позволяют проектировать систему, которая может расти и развиваться вместе с расширением и изменением требований системы. В этой связи требование гибкости и адаптивности должны быть встроены в систему. 3.1.3. Вспомогательные виды деятельности В процессе жизненного цикла разработки системы существуют виды деятельности, которые следует выполнять на протяжении всех этапов ЖЦ. К таким видам деятельности относятся: сбор информации — процесс использования обследований, интервью, встреч, анкетирования, создания прототипов и других технологий для сбора информации о системе, ее требованиях и предпочтениях заинтересованных лиц; документирование и презентации — средства взаимодействия различных категорий заинтересованных лиц. вовлеченных в процесс разработки системы. Документирование — деятельность, направленная на запись фактов и спецификаций системы. Презентация — вид деятельности, направленный на представление документации о системе, оформленной в интересах различных категорий заинтересованных лиц. Презентация может выполняться в виде со- общения или представляться в виде записки. Управление версиями документации при разработке сложных систем становится критическим фактором, поскольку необходимо учитывать множество различных версий документации, находящихся в различных стадиях разработки. Так например, может возникнуть необходимость учета текущей применяемой версии системы, предыдущей, а возможно, и новой разрабатываемой версии; оценивание и измерение — деятельность, направленная на повышение качества и производительности системы. Оценивание — вычисление примерного времени, трудоемкости, стоимостей и величины выгоды разрабатываемой системы, используемое для получения достоверных данных. Измерение направлено на получение и анализ оценок производительности и качества деятельности разработчика (и иногда стоимости). Некоторые аналитики опасаются высказывать оценки из-за неуверенности и неопределенности имеющихся данных. Более опытные аналитики привлекают для оценивания собственный и коллективный опыт, основанный на выполнении предыдущих проектов, и постоянно усовершенствуют систему оценок. Измерения становятся особенно актуальными из-за серьезного влияния производительности и качества разработки проблем на разработку системы; технико-экономический анализ представляет собой меру того, насколько выгодной и полезной в организации может быть разработка информационной системы; управление проектом и процессом разработки. В проектирование информационной системы вовлекается коллектив сотрудников, состоящий из аналитиков, программистов, пользователей и других профессионалов в области информационных систем, работающих как одна команда. Управление проектом представляет собой постоянную деятельность, в процессе которой аналитик планирует, распределяет обязанности, направляет и контролирует вы- полнение разработки системы в рамках выделенного времени и бюджета. Большинство проектов, которые заканчиваются неудачей, характеризуются недостаточным руководством и управлением. Плохое управление выражается невыполненными или неустановленными требованиями, превышением бюджета и задержками в разработке. Жизненный цикл разработки системы обеспечивает структурную основу для управления проектом системы. Управление процессом разработки имеет своей целью стандартизацию подхода и средств проектирова- ния, а также способа распространения готовой системы. Управление процессом разработки - деятельность, устанавливающая стандарты для выполнения этапов жизненного цикла, состав методов и моделей проектирования, использование инструментальных средств, а также требования к содержанию и оформлению результатов, которые производятся в процессе проектирования. 3.1.4. Содержание основных этапов жизненного никла Рассмотрим содержание основных этапов жизненного цикла разработки ИС. изображенных на рис. 3.1. Суть этапа анализа системы - сбор информации, необходимой для приобретения или разработки новой системы.Разработка системы начинается с предварительного определения основных проблем и задач ИС. а также функций, с помощью которых разрешаются выявленные проблемы. Описание функций выполняется на языке производственных (описание процессов предметной области), функциональных (описание формы обрабатываемых документов) и технических (аппаратное, программное, лингвистическое обеспечение) требований. Во многих организациях в результате предварительного изучения ситуации готовится формальный запрос на проектирование и разработку ИС. Чтобы максимизировать использование ограниченных ресурсов, требования к разработке системы ранжируются по степени важности. После начального этапа производится исследование используемой в данный момент ИС, чтобы определить ее природу, нацеленность и понять сильные и слабые стороны, определяются и документируются информационные потребности пользователей системы и менеджеров. Все это используется для разработки и документирования требований к системе. Далее требования к системе используются для выбора между разработкой и приобретением ИС. Руководству предоставляется отчет об анализе системы.  Рис. 3.1 Жизненный цикл разработки ИС На этапе концептуальной разработки компания решает, как удовлетворить свои потребности. Первая задача - определить и оценить возможные альтернативы. Если одна из альтернатив принята руководством для разработки, то формируется план разработки ИС, содержащий следующие ключевые элементы: • определение масштаба проекта, в рамках которого анализируются основные функции и взаимодействие с внешними системами; • более полное изучение формулировки проблем; • уточняются необходимые процессы обработки информации и ограничения; • рассматривается ресурсное обеспечение разработки: люди, время, финансовые средства для разработки и функционирования ИС. Ресурсное обеспечение исчисляется по аналогии с известными разработками; • готовится график выполнения различных этапов проекта. В заключение этапа анализа готовятся детальные спецификации, описывающие логическую модель ИС: схемы и структуры данных всех уровней, модульность ИС. документацию логической структуры, скрипты для создания объектов БД. Физическая разработка - это перевод общих, ориентированных на пользователя требований, сформулированных на этапе концептуальной разработки, в детальные спецификации, которые могут быть использованы при кодировании и тестировании компьютерных программ. Разрабатываются входные и выходные документы, пишутся компьютерные программы, создаются файлы, разрабатываются процедуры, в новую систему встраиваются способы ее контроля. Разработанные компоненты тестируются и отлаживаются. Внедрение - это этап, на котором соединяются воедино все элементы системы и начинается ее функционирование. Это очень ответственный и сложный этап, поэтому подготавливается и строго выполняется план внедрения. Как часть внедрения, устанавливается и тестируется все новое оборудование и программы, нанимается или обучается персонал, тестируются (и возможно корректируются) новые процедуры обработки данных, отрабатываются стандарты и способы контроля новой ИС, делается подробное документирование. В конце этого этапа происходит демонтаж старой системы и переход на новую. Эксплуатация и обслуживание. После того как система заработала, она изучается на предмет обнаружения и исправления недостатков разработки. В течение своей жизни система периодически пересматривается. Изменения в нее вносятся по мере возникновения проблем или появления новых потребностей. Если требуются существенные изменения системы, по сути означающие ее замену, то цикл разработки начинается сначала. В дополнение к этим пяти этапам на протяжении всего цикла разработки ИС производится планирование, управление поведенческими реакциями пользователей на изменения и оценка текущих возможностей всего проекта. Участники Для успешной разработки ИС должны сотрудничать очень многие люди. Во-первых, это руководство организации. Разработка не может быть успешной без ясной позиции высшего руководства по поводу ее необходимости. Обеспечение поддержки, установка целей разработки, анализ работы отдела автоматизации, определение политики по выбору системы, участие в принятии важнейших решений, выделение средств, назначения на ключевые посты - основные функции менеджеров при создании ИС. Роль пользователей (бухгалтеров, управленцев, других служащих, которые будут использовать систему) определяется тремя моментами. Они должны обозначить свои информационные потребности, они должны участвовать в самой разработке ИС и играть активную роль в оценке результатов ее деятельности. Поскольку разработка ИС не признает границ между подразделениями и функциями, организации учреждают руководящий комитет. Его задачи: планирование и контроль за разработками, установление стандартов и политики, координация действий. В его состав включаются представители всех вовлеченных в процесс разработки сторон. Группа разработчиков каждого проекта объединяет специалистов по ИС. менеджеров, бухгалтеров, аудиторов, других пользователей. В задачу группы входит планирование каждого отдельного проекта, обеспечение его своевременного и эффективного выполнения, взаимодействие с руководящим комитетом, аккумуляция и использование экспертных знаний, необходимых для разработки. Чтобы выполнить эти задачи, группа должна регулярно общаться с пользователями ИС и устраивать обсуждения новых идей и продвижений в выпол- нении проекта. Системные аналитики исследуют существующую систему, разрабатывают новую и готовят спецификации для программистов. Программисты разрабатывают новые и модифицируют существующие компьютерные программы. Планирование разработки системы Планирование ИС представляет собой принятие решений по следующим вопросам: • что представляют собой основные задачи, которые должна выполнять ИС для до- стижения целей системы; • за что возлагается ответственность на подразделение автоматизации и пользовате лей, и кто будет выполнять разработку ИС; • когда может быть завершена разработка ИС; • какая технология будет использована для разработки системы и какие технологии должны использоваться для выполнения разработки качественно и в срок. Одновременно должны быть определены желаемые результаты в терминах изменений выполняемых операций. Если ИС плохо спланирована, то ее использование и изменение может оказаться очень неудобным и дорогим процессом. Поэтому до того как приступить к разработке, проводится предварительное планирование, которое призвано добиться: последовательности. Цели и задачи системы должны соответствовать общему стратегическому плану организации; эффективности. Система должна быть построена и работать максимально эффективно, а ее подсистемы должны быть скоординированы; использования передовых технологий. Должны быть приняты решения, на основе каких технологиях будет строиться система; сокращения затрат. Необходимо избегать дублирования, никому не нужных работ, перерасхода бюджета и времени. Построенная система должна быть проста в эксплуатации; адаптивности. Руководство должно быть готово к новым потребностям, которые могут возникнуть в будущем, а работники - к будущим изменениям системы. Когда усилия по разработке плохо спланированы, компании приходится чаще возвращаться к уже пройденным этапам, что приводит к задержкам и повышению затрат. На рис. 4.2 показаны шаги процесса разработки и причины, приводящие к нежелательным возвратам на более ранние стадии. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.  Рис, 3.2, Причины для возврата на предыдущие шаги цикла разработки ИС В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем. что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 3.3). делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ИС. на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.   Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. На этапе предварительного планирования составляются планы двух типов. |