Методы проектирования информационной системы и функциональный анализ деятельности организации. Проектирование информационной системы

Проектированием информационных систем называется многоступенчатый процесс их создания и/или модернизации путём применения упорядоченной совокупности методологий и инструментария. Проектирование (в отличие от моделирования) предполагает работу с пока несуществующим объектом и направлено на создание информационной системы в области:

• обработки объектов будущей базы данных,
• написания программ (в том числе - отчётных и экранных форм), обеспечивающих выполнение запросов к данным,
• выполнения учёта функционирования конкретной среды (технологии).

Если выделять стадию проектирования информационных систем в качестве отдельного этапа, то его можно разместить между этапами анализа и разработки. Однако на практике чёткое разделение на этапы, как правило, затруднено или невозможно, поскольку проектирование, формально начинаясь с определения цели проекта, часто продолжается на стадиях тестирования и реализации.

Цель проектирования информационной системы и связанные понятия

Современные руководители государственных и частных организаций отдают себе отчёт в том, что скорость обработки информации, которая постоянно изменяется и растёт в объёме, – это вопрос выживания компании на рынке и конкурентное преимущество. В общем виде целевые установки проектов по созданию информационных систем сводятся к обеспечению условий, позволяющих эту информацию получать, обрабатывать и использовать путём создания функциональной безотказной системы с достаточным:

• уровнем адаптивности к изменяемым условиям,
• пропускной способностью,
• временем системной реакции на запрос,
• уровнем безопасности,
• степенью простоты в эксплуатации.

Информационной системой (ИС) называют совокупность информации, содержащейся в базе данных, и технологий (а также технических инструментов), обеспечивающих обработку информации. В данном случае, к технологиям относят и методы обнаружения, сбора, обработки, хранения, распространения информации, и способы, которые позволяют эти методы реализовать. Информационное управление при этом сводится к применению данных методов для контроля за процессами планирования, дизайна, эксплуатации и анализа ИС. В основе технологии проектирования лежит выбранная для конкретной задачи методология как совокупность принципов, выраженная в единой определённой концепции.

Организация проектирования ИС

Организацию проектирования ИС принято разделять на 2 типа:

1. Каноническое проектирование отражает особенности технологии оригинального (индивидуального) процесса.
2. Типовое проектирование, для которого характерно типовое проектное решение (ТПР), тиражируется и пригодно к многократному использованию.

Каноническое проектирование отличает отражение ручной технологии проектирования, осуществление на уровне исполнителей, использование инструментария универсальной компьютерной поддержки.

Применяется каноническое проектирование, главным образом, для локальных и относительно небольших ИС с минимальным использованием типовых решений. Адаптация проектных решений происходит только посредством перепрограммирования программных модулей.

Организовывается каноническое проектирование с использованием каскадной модели жизненного цикла. Это предполагает разделение процесса на следующие стадии и этапы:

1. Предпроектная стадия. Производится и составляется техническое задание. То есть, формируются требования к ИС, разрабатывается её концепция, составляется технико-экономическое обоснование и пишется ТЗ.
2. Проектная стадия предусматривает составление эскизного и технического проектов, разработку рабочей документации.
3. Послепроектная стадия даёт старт мероприятиям по внедрению ИС, обучению персонала, анализу результатов испытания. Частью этой стадии становится сопровождение ИС и устранение выявленных недостатков.

Этапы, в случае необходимости, можно укрупнять или детализировать – объединять последовательные этапы, исключать «лишние», начинать выполнение очередной стадии до завершения предыдущей.

Метод типового проектирования отличается возможностью декомпозиции проектируемой ИС с разделением на компоненты, в число которых входят программные модули, подсистемы, комплексы задач и др. Для реализации компонентов можно воспользоваться типовыми решениями, которые уже существуют на рынке, и настроить их под нужны конкретной организации. При этом типовое проектирование предполагает обязательное наличие документации, описывающей в деталях ТПР и процедуры настройки.

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

• элементные – по отдельной задаче (элементу),
• подсистемные – по отдельным подсистемам,
• объектные – отраслевые типовые проектные решения, содержащие весь набор подсистем.

Возможность реализации модульного подхода считается достоинством элементных ТПР. Однако в случае несовместимости разных элементов процесс их объединение приводит к увеличению затрат. Подсистемные ТПР, помимо реализации модульного подхода, дают возможность провести параметрическую настройку на объекты разных уровней управления. Проблемы с объединением возникают в случае привлечения продукта нескольких разных производителей ПО. Кроме того, адаптивность ТПР с позиций непрерывного реинжиниринга процессов считается недостаточной. Объектные ТПР, по сравнению с предыдущими классами, отличаются большим количеством достоинств:

• масштабируемостью, что делает возможным применение конфигураций ИС для разного числа рабочих мест,
• методологическим единством компонентов,
• совместимостью компонентов ИС,
• открытостью архитектуры – возможностью развёртывать проектные решения на платформах различного типа,
• конфигурируемостью – возможностью применения нужного подмножества компонентов ИС.

В ходе реализации типового проектирования применяются параметрически-ориентированный и модельно-ориентированный подходы.

Основные методологии проектирования ИС

Специфические особенности процесса проектирования позволяют выделять методологии, построенные на разных принципах. Среди основных современных методологий проектирования ИС называют следующие:

• SADT . Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
• RAD . Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
• RUP . В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

Существуют несколько классификаций методологий: по использованию ТПР, по применению средств автоматизации и др. Например, по степени адаптивности выделяются реконструкции (когда происходит перепрограммирование модулей), параметризации (когда изменение параметров влечёт за собой генерацию проектного решения), реструктуризации (когда изменение модели проблемной области сопровождается автоматическим генерированием проектного решения).

Любое предприятие, фирма, организация обладает своей организационной структурой. Эта структура многомерна и может быть расчленена на несколько взаимосвязанных и взаимозависимых подструктур, которые можно рассматривать как самостоятельные структуры структура управления производством, кадровая структура, маркетинговая, финансово-экономическая, информационная структуры.

Все они находятся в тесном взаимодействии и именно их совокупность и создат организационную структуру предприятия. Одно из важнейших мест в этой структуре занимает информационная система. В принципе, любую систему управления можно представить как информационную систему с различными информационными потоками в виде документов, распоряжений, запросов, обращающихся внутри организации, исходящих или входящих из внешней среды.

В последние десятилетия резко увеличился объм информации в обществе вообще и информации, используемой на предприятии в частности. Это связано с растущими темпами развития науки и техники, появлением новых технологий, быстрой их сменяемостью. На рынках сырья и продукции сложились условия, требующие постоянного наблюдения за состоянием рынка, его изменениями, тенденциями его развития, необходимо уметь предвидеть дальнейшее развитие ситуации и быть готовым к смене стратегии, стиля деятельности, технологии производства для быстрейшего приспособления к новым внешним условиям. Вс это ведт к тому, что в современных условиях руководителям предприятий приходиться иметь дело с таким большим количеством информации, она так быстро меняется, что е часто становится просто невозможно обработать вручную. Кроме того, на больших предприятиях с большими оборотами продукции и численностью работников существует необходимость учта и контроля большого объма финансовой, производственной, кадровой, закупочно-сбытовой, маркетинговой информации. В связи с этим появляется необходимость создания автоматизированных систем сбора, обработки, хранения информации. Они должны облегчить процесс работы с информацией, циркулирующей на предприятии.

Появление компьютерной техники позволяет создать подобные системы. На современных предприятиях практически вся работа с информацией автоматизирована, существуют специальные программы, позволяющие вести на компьютере бухгалтерский учт, документооборот, маркетинговые исследования, проводить прогнозирование и стратегическое планирование, а также многое другое. Но кроме автоматизации актуальным остатся вопрос о грамотном построении структуры информационной системы, оптимизации информационных потоков, отсеивания ненужной информации, упрощения поиска и получения необходимой. Наличие хорошо отлаженной автоматизированной информационной системы на предприятии значительно упрощает процесс управления предприятием. Она позволяет вовремя собрать, отсортировать, обработать необходимую информацию и принять верное решение. Иногда, не вовремя принятое решение, из-за недостатка или несвоевременного поступления информации может привести к гибели предприятия. Поэтому необходимо уделять большое внимание созданию и поддержанию эффективного функционирования информационной системы предприятия.

Основными понятиями, используемыми в теории информационных систем и автоматизированных систем информации, являются информация, система, информационно-поисковая система, автоматизированная система управления, автоматизированное рабочее место. Информация - от лат. Informatio разъяснение, изложение первоначально сведения, передаваемые людьми устным, письменным или другим способом с середины 20-го века общенаучное понятие, включающее обмен сведениями между людьми, человеком и автоматом, автоматом и автоматом. Система группа множество определнным образом упорядоченных и взаимосвязанных элементов, обладающих устойчивым единством, внутренней целостностью, автономностью существования во внешней среде. Информационно-поисковая система ИПС совокупность средств для хранения, поиска и выдачи по запросу нужной информации, поиск размещение информации в ИПС осуществляется вручную или с помощью ЭВМ по определённым правилам и в соответствии с принятым информационным языком. Автоматизированная система управления АСУ совокупность математических методов, технических средств ЭВМ, средства связи и организационных комплексов, обеспечивающих рациональное управление сложным объектом процессом в соответствии с заданной целью. Автоматизированное рабочее место АРМ рабочее место оператора, диспетчера, конструктора, технолога, оснащенное средствами вычислительной техники для автоматизации процесса переработки и отображения информации, необходимой для выполнения производственного задания. В последнее время возросла роль информации, используемой на предприятиях, в различных организациях. Можно сказать, что она является одним из ресурсов, используемых в деятельности предприятия. Однако информационные ресурсы отличаются по своим свойствам от ресурсов в традиционном понятии материальных, энергетических, технологических.

Разными исследователями предлагались различные способы классификации информационного обеспечения. Так с точки зрения взаимодействия предприятия организации с окружающей средой всю информацию в основном документальную принято делить на входящую и исходящую. В зависимости от сроков хранения различают постоянную, условно-постоянную иногда обновляемую и переменную регулярно изменяющуюся. Разделяют информацию и по уровням управления заводская, внутризаводская, цеховая, внутрицеховая. По характеру деятельности конструкторско-технологическая. бухгалтерская, учтно-отчтная, плановая, маркетинговая, кадровая, производственная. В автоматизированных системах информационное обеспечение делят на машинное в памяти ЭВМ и внемашинное. Эти классификации в различных сочетаниях используются при индексировании различных документов писем, приказов, инструкций и других документов, используемых предприятиями и организациями в своей практической деятельности. История развития. В истории создания автоматизированных информационных систем относительно независимо развивались два направления 1. разработка автоматизированных информационных систем АИС как автоматизированных систем управления АСУ 2. разработка автоматизированных систем научно-технической информации АСНТИ. Работы по их созданию начались практически одновременно в 60-е гг.

Первое направление - разработка АИС и АСУ - было инициировано научно-техническим прогрессом и возникшими в связи с этим проблемами организационного управления рост количества информации, трудности с е обработкой вручную. Зарубежная практика шла по пути разработки отдельных программных процедур, например, для бухгалтерии, учета материальных ценностей, и основные работы проводились в направлении исследования и совершенствования возможностей вычислительной техники, разработки средств, обеспечивающих наиболее рациональную организацию информационных массивов, удобный для пользователя интерфейс, наращивание памяти ЭВМ. В нашей стране проблема обеспечения информацией управленческих работников была поставлена сразу системно. Была разработана классификация АСУ, в которой прежде всего выделялись АСУ разных уровней системы управления - для уровня предприятий и организаций, отраслевые, республиканские и региональные и общегосударственная автоматизированная система.

Аналогично на уровне предприятий, и особенно создаваемых в 70-е гг. научно-производственных объединений НПО, в структуре АСУП или интегрированных АСУ объединений выделялись уровни страты - АСУ объединения, АСУ предприятий и организаций научно-исследовательских институтов, конструкторских бюро, входящих в НПО, АСУ производств, комплексов цехов, АСУ цехов и участков. На уровне цехов и участков АСУ вначале разделялись на АСУ технологическими процессами, АСУ технической и технологической подготовки производства, АСУ организацией производства. Работы по созданию централизованных общегосударственных АСУ и АСНТИ были приостановлены в связи с преобразованиями 19-91 гг. Однако, при переходе к рыночной экономике, к правовому государству возрастает роль еще одного важного вида информации - нормативно-правовой и нормативно-методической, регламентирующей деятельность предприятий при предоставлении им большей самостоятельности и сокращении организационно-распорядительной документации текущих приказов и распоряжений, ревизующих командно-административные методы управления. В дальнейшем, по мере развития предприятий и их АСУ, особенно в условиях предоставления большей самостоятельности производствам и цехам и перераспределению управленческих функций между администрацией предприятия и руководителями производств и цехов, также стало более удобным представлять структуру АСУ в виде многоуровневой, стратифицированной. Разделение АСУ на функциональную и обеспечивающую части, а последней - на информационное обеспечение, техническое, организационное, программное и другие виды обеспечения - позволило привлечь для уточнения соответствующих видов обеспечения специалистов в этих областях. Такой подход к организации разработок АСУ помог справиться со сложностью системы и ускорить разработку АСУ путем параллельного проведения работ по анализу и выбору структуры отдельных видов обеспечения. Однако, если разрабатывать отдельные проекты, то после разработки возникает достаточно сложная задача их согласования, взаимоувязки принятых структур этих видов обеспечения, критериев, учитываемых при их разработке и. Поэтому на определенном этапе развития работ по созданию АСУ был даже сформулирован специальный принцип единства информационного обеспечения, технического и программного, как основных видов обеспечения. В настоящее время существует огромное количество готовых программных продуктов. Поэтому, нет необходимости при создании на предприятии автоматизированной системы заниматься самостоятельной разработкой прграммного обеспечения. Оценка эффективности информационных ресурсов. При многообразии видов и форм информационных ресурсов проблема их оценки кажется практически неразрешимой.

Действительно, как сопоставлять различные виды информации Какой информацией необходимо обеспечивать руководителей, управленческих работников, научных работников, конструкторов, технологов и других сотрудников предприятия Как определить, хранение и поиск какой информации важнее автоматизировать в первую очередь Как вообще определить эффективность использования информационных ресурсов.

Увеличение объемов производства, частоты обновления номенклатуры выпускаемой продукции и технологий усложнение управления быстро развивающимися регионами, производственными системами, непромышленной сферой привели к увеличению и усложнению информационных потоков. В этих условиях стало необходимым оценивать затраты на информационные ресурсы, определять их вклад в эффективность функционирования производственных, образовательных и других систем.

В различных науках об информации предпринимались попытки ее измерения. Для оценки удовлетворения информационных потребностей в теории научно-технической информации введены меры релевантности и пертинентности. Под релевантностью понимается соответствие выдачи запросу под пертинентностью - соответствие выдачи потребностям пользователя. На практике при оценке значимости информационных массивов автоматизированных систем управления пользуются иногда такими косвенными оценками, как частота обращения к массиву, число подготавливаемых на его основе документов, число обслуживаемых подразделений, объем массивов и т. п. косвенными количественными характеристиками. Для решения частных задач рассмотренные способы оценки информации дают иногда вполне удовлетворительные результаты. Однако в случае оценки всей совокупности информационных ресурсов желательно иметь возможность сравнивать различные виды информации, получать если не единую меру, то хотя бы сопоставимые оценки полезности различных информационных ресурсов для производственной или иной системы, с тем чтобы распределять средства на информационное обеспечение более рационально. Применить для оценки эффективности информационных ресурсов традиционную стоимостную меру практически нереально. Можно, конечно, оценить экономическую эффективность и срок окупаемости автоматизации хранения и поиска отдельных видов информационного обеспечения. Однако на основе этих оценок нельзя судить о значимости информации для совершенствования производства или системы организационного управления, о полезности информации для научных исследований, проектного решения. Опираясь на основную идею применения системных представлений при организации сложных экспертиз можно поставить задачу оценки эффективности информационных ресурсов, как задачу оценки степени их влияния на реализацию цепей системы.

При такой постановке задачи нужно решить две проблемы 1 сформировать структуру целей основных направлений развития системы, определяющих ее деятельность в соответствующий период сyщecтвoвaния 2 выбрать подход к оценке степени влияния информации на достижение целей. Для обеспечения полноты анализа деятельности предприятия организации при формировании структуры целей следует применять методики структуризации целей и функций, выбор которых определяется предварительно разработанной концепцией его развития. Для оценки степени целесоответствия можно использовать вероятностную меру, т. е. оценивать вероятность того, что данный информационный ресурс будет использован при достижении подцели. Такие оценки можно получать, как оценки относительной важности, относительного вклада информационного ресурса в реализацию соответствующей подцели, однако при этом возникает проблема, связанная с тем, что одна и та же информация может влиять не на одну подцель. Можно использовать информационную меру степени влияния ресурса на реализацию подцелей, которая позволяет учесть не только вероятность достижения подцели p, но и вероятность q того, что данная информация будет использована лицом, принимающим решение, при реализации подцели. Оценка информационного потенциала H удобнее оценок относительной важности их можно суммировать можно учесть не только p но и q понятие информационного потенциала лучше воспринимается управленческими работниками. В реальных условиях могут быть использованы более сложные способы.

Сервисный центр - организация, занимающаяся оказанием услуг по сервисной поддержке и обслуживанию техники, оборудования и другой продукции. Деятельность сервисных центров включает предторговый, гарантийный и послепродажный ремонт.

Предприятие ИП Михайлов А.О. занимается ремонтом и обслуживанием бытовой техники и электроники, также компьютеров, телефонов и планшетов, которые клиенты привозят в офис, а также заправке картриджей и монтаже сетей и офисных АТС. При отсутствии возможности доставить технику самим клиентом осуществляется выезд на место, и при необходимости доставляется силами сервисного центра. При обращении клиента в сервисный центр, диспетчер оформляет заявку на принятие заказа. Проводится анализ объекта, в результате которого осуществляется вывод, будет ли выполнен ремонт техники или нет. Инженерный отдел составляет прайс-лист по ремонту и обслуживанию техники, так как он работает с поставщиками запчастей и устройств для ремонта техники. Ремонт проводиться специальным оборудованием соблюдая правила безопасности. Так же предприятие занимается продажей периферийных устройств для телефонов, планшетов и компьютеров. Предприятие занимается покупками б/у техники и техники вышедшей из строя.

На предприятии работают квалифицированные специалисты с многолетним опытом работы. Директор руководит всей работой предприятия.

Адрес предприятия:

Пермский край, г. Кунгур, ул. Ленина 66

Режим работы:

ПН-ПТ: 10 - 19 без обеда

ВС: выходной.

Структурировав перечень услуг, предприятие может повысить свою прибыль, расширить границы предприятия или открыть ещё один сервисный центр в другом месте, так же может повыситься качество предоставляемых услуг и увеличиться количество клиентов.

Проведённый анализ предметной области предоставляет полное описание предметной области предприятия ИП Михайлов А.О. для создания работоспособной информационной системы по данному предприятию. Приведено описание работы сервисного центра с указанием работы инженерного отдела. Так же создана организационная структура предприятия, которая показывает взаимодействие директора и подчинённых.

Формирование базовых документов по управлению проектом информационной системы

Проект - это совокупность задач или мероприятий, связанных с достижением запланированной цели, которая обычно имеет уникальный и неповторяющийся характер.

Управление проектом (Project Management) - использование знаний, навыков, методов, средств и технологий при выполнении проекта с целью достижения или превышения ожиданий участников проекта.

Для того чтобы правильно управлять проектом информационной системы, нужно сформировать базовые документы по управлению проектом. Базовыми документами будут являться Устав и План управления проектом.

Устав проекта

Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации.

В Уставе проекта документируются первоначальные требования к проекту, удовлетворяющие потребностям и ожиданиям заинтересованных сторон.

Присутствует устав проекта.

Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации.

Устав проекта должен содержать следующую информацию:

Требования к проекту и продукту проекта, в достаточно общем виде;

Цель проекта;

Информация о назначенном менеджере проекта и уровне его полномочий;

Расписание контрольных событий;

Отношения между участниками проекта;

Функциональные организации и их участие;

Допущения относительно организации и окружения, а также внешние допущения;

Ограничения относительно организации и окружения, а также внешние ограничения;

Реальная бизнес-ситуация, служащая обоснованием проекта с данными о прибыли на инвестиции;

Бюджет проекта.

Устав проекта повышает вероятность успешного завершения проекта. Он документирует намерения участников проекта в самом начале проекта и может служить основополагающей точкой разрешения споров между участниками проектной команды и исполняющей организацией.

При составлении устава проекта было выполнено установление устава правил организации работ по проекту с помощью документирования, стратегий, целей, методологии ведения проекта, ролевых функций и правил проекта, необходимых для достижения бизнес-целей проекта. Определены ответственные за управление и реализацию.

Разработка устава занимает значительное время. При создании следующего проекта, разработанный устав можно будет использовать как шаблон, что бы разработка устава заняла меньше времени. Устав проекта помогает при управлении проектом, так как некоторая информация необходимая для работы в MS Project.

План управления проектом

План управления проектом (Project Management Plan) - пакет утвержденных формальных документов, в которых указано, как проект будет исполняться, и как будет происходить мониторинг и управление проектом. План может быть обобщенным или подробным, а также может включать один или несколько вспомогательных планов управления и другие документы по планированию.

Процесс разработки плана управления проектом есть процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. Корректно составленный план управления проектом является основным источником информации о том, как проект будет планироваться, оцениваться, контролироваться и закрываться. План управления проектом обновляется и редактируется в рамках процесса осуществления интегрированного управления изменениями проекта.

1 Вспомогательные планы управления проектом, в число которых входят:

План управления содержанием проекта;

План управления расписанием проекта;

План управления стоимостью проекта;

План управления качеством проекта;

План управления обеспечением персоналом;

План управления коммуникациями проекта;

План управления рисками проекта;

План управления конфигурацией.

2 Базовая линия проекта, состоящая из:

Базового расписания проекта;

Базового плана по стоимости;

Базового плана по качеству;

Базового плана по конфигурации;

Реестра рисков.

3 Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.

Для проекта информационной системы «Учёт оказываемых услуг» создан план управления проектом. (Приложение Б)

В первом пункте плана управления проектом указывается название проекта. Название проекта нельзя изменять на протяжении всего жизненного цикла проекта.

Во втором пункте определяются цели и задачи проекта. Цели формируются исходя из требований заказчика, которые заключаются в автоматизации основных бизнес-процессов предприятия. Были поставлены цели, такие как привлечение клиентов и увеличение прибыли, повышение качества предоставляемых услуг.

Третий пункт определяет требования к проектному решению и результаты проекта. Этот раздел является элементом базового содержания проекта. Для обеспечения связи между требованиями заказчика и результатами проекта рекомендуется использовать функцию качества.

Четвёртый пункт определяет границы проекта. Это базовый элемент содержания проекта. В границах проекта описывается, что включается в проект, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.

Пятый пункт определяет инструменты и технологии для реализации управления проектом.

В шестом пункте находиться иерархическая структура работ - модель, раскрывающая проект уровень за уровнем до такой степени детализации, которая необходима для эффективного планирования и контроля проекта.

Седьмой пункт описывает потребность в ресурсах. Она определяется трудоемкостью работ, отраженных в разработанной ранее ИСР.

Восьмой пункт Плана показывает укрупненный календарный план. Он разрабатывается на основе контрольных событий, информации из Устава проекта и информации из используемой методологии проектного управления.

Девятый пункт критические факторы успеха. Он описывает условия, обеспечение которых на проекте может быть залогом успеха.

Десятый и одиннадцатые пункты отображают допущения и ограничения со стороны исполнителя. При реализации проекта ограничения могут быть изменены.

Двенадцатый пункт первоначально сформулированные риски. Указываются уже известные риски и основные категории потенциальных рисков.

Управление рисками - это процессы, связанные с идентификацией, анализом рисков и принятием решений, которые включают максимизацию положительных и минимизацию отрицательных последствий наступления рисковых событий.

Планирование управления рисками - процесс принятия решений по применению и планированию управления рисками для конкретного проекта. Этот процесс может включать в себя решения по организации, кадровому обеспечению процедур управления рисками проекта, выбор предпочтительной методологии, источников данных для идентификации риска, временной интервал для анализа ситуации.

Планирование управления рисками - выбор подходов и планирование деятельности по управлению рисками проекта.

1 Идентификация рисков - определение рисков, способных повлиять на проект, и документирование их характеристик.

2 Качественная оценка рисков - качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

3 Количественная оценка - количественный анализ вероятности возникновения и влияния последствий рисков на проект.

4 Планирование реагирования на риски - определение процедур и методов по ослаблению отрицательных последствий рисковых событий и использованию возможных преимуществ.

5 Мониторинг и контроль рисков - мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.

План управления рисками представлен. (Приложение В)

Плана управления проектом информационной системы «Учёт оказываемых услуг» позволил создать документы и описать характеристики и границы проекта, связанные с ним услуги, а также методы приемки и управление содержанием. Описание содержания позволило оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта.

Разработка базовой документации по управлению проектом информационной системы «Учёт оказываемых услуг» позволила описать часть документов для качественной и благополучной реализации управления проекта в MS Project. Залогом успеха является понимание необходимости данных документов в процессе управления проектами. Результатом данной работы стали, разработанные устав проекта и план управления проектом, которые будут использованы в дальнейшей работе.

Результатом первого раздела стала структуризация проекта ИС «Учёт оказываемых услуг» для предприятия ИП Михайлов А.О., так же разработаны устав проекта и план управления проектом, которые были использованы в дальнейшей работе по управлению проектом. Процесс формирования базовых документов это важнейшая часть управления проектом, так как она влияет на качество, длительность и успешность проекта.

Введение

Заключение

Литература

Введение

Развитие различных сфер человеческой деятельности на современном этапе невозможно без широкого применения вычислительной техники и создания информационных систем различного направления. Обработка информации в подобных системах стала самостоятельным научно – техническим направлением.

После этапа построения информационной модели начинается проектирование системы. На этом этапе производится выбор технологических решений, на основе которых будет построена информационная система.

Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности.

В реальных условиях проектирование - это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.

Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации.

Целью контрольной работы является - рассмотреть поэтапно, процесс создания информационных систем.

Задачи данной работы – выяснить главную цель проектирования, а также цель создания информационных систем.

1. Проектирование информационных систем

Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:

· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

· требуемую пропускную способность системы;

· требуемое время реакции системы на запрос;

· безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;

· простоту эксплуатации и поддержки системы;

· необходимую безопасность.

Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

· учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

Процесс создания ИС делится на ряд этапов (стадий ), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.

Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.

На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.

Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.

Конечными продуктами этапа проектирования являются:

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:

· будет ли это архитектура "файл-сервер" или "клиент-сервер";

· будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

· будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;

· будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

· будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB).

Этап проектирования завершается разработкой технического проекта ИС. На этапе реализации осуществляется создание программного обеспечения эксплутационной документации.

После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

· обнаружение отказов модуля (жестких сбоев);

· соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.

Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.

Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.

Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.

Мы выбрали строительный проект, потому что на нем проще всего продемонстрировать, как спроектировать ИС. Информационная система скрыта где-то внутри, мы ее не видим, а стены - вот они перед нами: кривые и косые, с тупиковыми коридорами, потому что проект был сделан на коленке, да еще и заказчик свои требования менял сто раз по ходу пьесы.

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

Не программное обеспечение вы разрабатываете… Возьмем Android, - это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.

Отличие очевидно. Если вы купили телефон- все просто: включаете его, запускается зеленый человечек (Android), пользуетесь. А если вы приобрели коробку с бухгалтерским ПО, то ясно, что теперь необходимы сервера, надо настроить сеть, сконфигурировать рабочие станции, обучить сотрудников, интегрировать систему с остальными ИС предприятия, погонять систему в тестовом режиме. Да и бухгалтеров надо еще как-то уговорить перейти на новый софт, далеко не все из них готовы к новациям. В общем, в любом IT-проекте 10-20% это IT, а все остальное - организационные и административные меры, ну и очень плотная, ювелирная, работа с персоналом.

И, наконец, вспомним определение системы еще из далеких 90-х годов, которое никто не отменял:

Автоматизированная система: система, состоящая из персонала и комплекса средств автоматизации его деятельности , реализующая информационную технологию выполнения установленных функций.

ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.

Как спроектировать больницу

Однако, если вы серьезная организация, то сперва предложите заказчику ПРОЕКТ строительства. Согласны? А почему с Информационной Системой не так? Может, дело не в различиях между строительством и разработкой ПО, а в том, что в случае той же больницы сначала много думают, планируют, а потом строят, а ПО сначала разрабатывают и затем думают? Не потому ли много слышно о криворуких программистах, но ничего о таких же гастарбайтерах на стройке? Строители работают по проекту, в отличие от разработчиков.

Рассмотрим теперь процесс проектирования подробнее. В нем несколько стадий. Зачем же нужно проходить несколько этапов, почему за один раз не сделать? Для ясности приведу школьный пример… Сколько лет в школе изучают операцию умножения? Вы скажете - один-два месяца, и будете в корне неправы. Да, как умножать 5 на 6, проходят за неделю. Еще определенное время учат таблицу умножения. А умножение дробей, чисел со степенью, логарифмов, выражений в скобках, комплексных чисел, возведение в степень сколько изучают? Почти все школьные годы! Получается, мы одно и то же умножение изучаем каждый год под разными угл
ами.

Так вот, любой процесс и обучения, и проектирования, цикличен. Сначала мы получили общие понятия о числах, потом научились выполнять с ними простейшие действия, затем узнали про дроби и научились с ними работать, и так далее.

Сначала мы поняли, какую проблему должны решить с помощью Информационной Системы. Затем определили круг решаемых задач, поняли, ЧТО должна делать система, какие действия должен выполнять персонал. Потом определили, КАК система должна выполнять определенные ранее задачи. Эти этапы можно перескочить, только придется возвращаться обратно и все переделывать: семь раз отмерить и один раз отрезать получается гораздо быстрее, чем наоборот, да и материала уйдет меньше.

Приведем еще пример. Вы на вершине горы смотрите вниз в сильный бинокль и пытаетесь составить детальный маршрут спуска. В окуляры можно рассмотреть каждый камешек на тропинке, каждую лужу. Но вот та ли эта тропинка и ведет ли она на вершину, в бинокль не видно: отсутствует общий план. Разумный альпинист сначала невооруженным глазом наметит пути спуска, а затем их будет рассматривать под сильным увеличением. Как только вы окунаетесь в детализацию, теряете общий взгляд на проект. Взяв сразу подзорную трубу, вы идеально опишите 10 функций, при этом забудете про 40 остальных, вообще про них не упомянете.

Сложность поэтапного проектирования в том, что в начале процесса приходится оперировать абстрактными понятиями. Так хочется «пощупать» что-то готовое, а не говорить о неких требованиях, функциях, задачах, процессах. Нарисовать сразу интерфейс пользователя проще, но и легче упустить как минимум половину требований. Если же вначале составить детализированный список операций, которые должен выполнить пользователь при работе с той или иной экранной формой, то дизайнеру останется только нарисовать, а не фантазировать, как это часто бывает.

Теперь наконец-то перейдем к рассмотрению стадий проектирования.

1. Составление общих требований

Но конечно речь не о вас. Вы - профессионал и начинаете задавать кучу «глупых» вопросов. И самый главный из них - зачем нужно строить больницу. Какова цель строительства. Если цель не понятна, то вы не сможете ответить на вопрос, большая это должна быть больница или маленькая, какого профиля, чем оснащенная. К сожалению, заказчики зачастую говорят очень много всего интересного, кроме главного, - какова их цель. Вот это надо «вытащить» из него в первую очередь. И задать вопрос должны вы. Сам заказчик - не специалист, у него есть идея, и на этом он видит свою роль выполненной. Он не понимает, какой путь необходимо пройти для реализации его идеи. Как правило, заказчик ждет старого доброго чуда - прийти на берег моря, закинуть невод (заплатить деньги), выловить рыбку, и она исполнит его желание… А случается как в анекдоте про богатого мужика, который поймав золотую рыбку, попросил выполнить одно желание: «Хочу, чтобы у меня все было!» - «Нет проблем, - ответила рыбка, - у тебя все было...»

Чтобы вникнуть в цель проекта, недостаточно составить пару предложений со стандартным набором фраз. Цель проекта обычно определяется на основе противопоставления: описывают существующую информационную модель (например, сидят люди в архиве и бумажки перебирают), затем - ее недостатки (из-за отсутствия автоматизации в архиве задействовано 10 человек, что явно избыточно, другие отделы не могут неделями получить из архива нужную им информацию и т.д.) и предлагают решение (внедрить ПО, которое позволит осуществлять в автоматизированном режиме ряд операций, операции надо перечислить). В случае, если на рынок выводится совершенно новый вид сервиса, то требуется изучить существующий рынок и «покритиковать» имеющиеся там инструменты, затем предложить решение.

Кроме того, на данной стадии необходимо определить, какие требования законодательства необходимо учесть, как юридически оформить те или иные операции, как будет монетизироваться новый сервис, как планируется выходить на рынок, как заинтересовать внешних участников новой системы.

Иными словами, необходимо составить бизнес-модель. С одной стороны, это как бы и не задача разработчиков, а, с другой, без четкого определения цели и способов ее реализации непонятно, какие задачи должна решать система. А если заказчик сам толком еще не сформулировал, что ему нужно, вряд ли он будет доволен хоть каким-нибудь результатом.

2. Выбор концепции системы

3. Разработка Технического Задания

Для Информационной Системы разработка ТЗ () - центральная часть проекта. описывает:

1. ЧТО должна делать система.
2. Какова должна быть общая структура системы.
3. Как создать систему.

При описании функций системы (а это центральная часть ТЗ) следует понимать - мы приводим требования к тому, ЧТО должна делать система, а не КАК. Для вас должна быть важнее широта охвата, а не глубина. Например, на первой стадии (составление общих требований) мы выявили необходимость наличия функции блокировки входа пользователя. В ТЗ указали, что учетная запись блокируется при неиспользовании в течение 90 дней или после 6-и неудачных попыток входа, доступ может быть ограничен администратором на определенный срок, при попытке входа заблокированного пользователя необходимо выводить сообщение и т.д. А в техническом проекте (забежим вперед), мы с вами нарисуем макет карточки пользователя с флажком блокировки и датой разблокировки, составим сценарий входа в систему, в котором производится проверка на блокировку, автоматическая разблокировка по истечении установленного срока, блокировка в случае неудачных попыток входа; определим, что выполняется на стороне клиента, а что - сервера.

Хочется развенчать несколько мифов, связанных с разработкой .

Миф первый: В ТЗ содержатся требования только к исполнителю.

Нет, ТЗ - это то, как создать систему, и в техзадании есть разделы, в которых можно описать распределение ответственности.

4. Разработка технического проекта

При разработке технического проекта Информационной Системы необходимы документы, содержащие следующее: подробные сценарии, описывающие работу и взаимодействие разрабатываемой системы, пользователей и смежных систем; детальные макеты пользовательского интерфейса, содержащие описание типа данных и поведения каждого элемента интерфейса (значение по умолчанию, условия, при которых можно изменить значение поля, видимость, действия, выполняемые системой при изменении элемента и т.п.); описание протоколов для интеграции со смежными системами и оборудованием, формы отчетов и описание алгоритма их формирования, структуру серверов и баз данных, если их несколько.

Обычно этого более чем достаточно, чтобы была возможность отдать документы разработчикам и получить вменяемый результат. Детальные макеты и сценарии дают достаточно информации о поведении системы и интерфейса, а также о структуре данных. Разработчики будут поставлены в жесткие рамки, в которых фантазировать можно, но потом будет не отвертеться.

Надеюсь, в следующих статьях мы более подробно рассмотрим то, как качественно выполнить техническое проектирование, как разработать макеты, сценарии, какие документы необходимо составить.

5. Разработка рабочей документации

Наличие руководств пользователя и администратора для ИС - это стандарт, с этим все понятно. А вот о процессе сдачи-приемки системы заказчику часто задумываются в последний момент. И напрасно. Для этого существует прекрасный документ «Программа и методика испытаний», тоже обычно относящийся к рабочим документам. Он представляет собой своего рода чек-лист, содержащий описание проверочных процедур. Если данный документ составлен заранее (а сценарий, как основу, можно из техпроекта позаимствовать), то у разработчиков будет четкий критерий приемки их работ. Вам не понадобится собственным или аутсорсинговым программистам доказывать свою правоту - есть сценарий, он должен отрабатываться. И с заказчиком проблем не будет - фантазия уже ограничена документом.

А где же здесь место для Agile?

Вот скажите мне, любители Agile, можно ли пользуясь данной технологией, определить результат, который вы получите в конце разработки, стоимость и сроки? Нет? Ну и много ли дураков заказчиков таких найдете, которые ввяжутся в работу с неясным результатом, бюджетом и длительностью? Вы бы заказали ремонт квартиры бригаде, пользующейся Agile? Таким образом, Agile имеет место быть, но для проектов внутренних. Сами себе ремонт можете делать сколько угодно и несколько раз все пересматривать. Для внешних же заказчиков - это названный умным термином развод (вы, конечно, не согласитесь с такой формулировкой, но попробуйте убедить в том же клиента).

Во-вторых, Agile хорош в инновациях, там, где не понятно, какой результат требуется получить, или не ясен путь его достижения. Называется это ОКР, опытно-конструкторскими разработками. Или даже НИОКР - научно-исследовательские и опытно-конструкторские работы. На любом заводе имеется опытный цех, где с напильником, несколько раз переделывая, получают опытные образцы. Представим, что нужно разработать заново тачскрин, все жесты и поведение. Здесь действительно следует пробовать и пробовать, заранее поведение не опишешь. Но часто ли перед вами задачи подобного толка? Следует различать инженерные разработки и научно-исследовательские. В основном мы - инженеры по конструированию информационных систем.

В-третьих, в большом проекте могут присутствовать этапы, где требуется именно ОКР, и тогда Agile в помощь. Никто не мешает на уровне оперативного планирования пользоваться спринтами. Наоборот, очень удобная технология: планировать на неделю или две и постоянно контролировать результат. На стратегическом уровне - каскадное планирование, на тактическом - итеративное. И никаких противоречий!

К сожалению, очень часто, «проповедуя» Agile, разработчики пытаются замаскировать свое неумение разработать проект системы (либо даже не знают, что это возможно). Они действуют самым удобным для них образом: будем допиливать и допиливать за деньги заказчика. Пока расходы никто не контролирует, это вполне сходит с рук. Но потом у стороннего наблюдателя (начальства) может возникнуть ощущение, что процесс-то есть, а конца и края, да и результата не видно. Пытайтесь смотреть не только со своей колокольни.

Где узнать подробнее о проектировании информационных систем?

Теги: Добавить метки