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

Часть 1. Этапы разработки проекта: стратегия и анализ

Введение "Водопад" - схема разработки проекта Стратегия Анализ ER-диаграммы Дуги Нормализация Диаграммы потоков данных Некоторые принципы проверки качества и полноты информационной модели Качество сущностей Качество атрибутов Качество связи Функции системы Уточнение стратегии

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если разобраться, то так ли уж непредсказуемо развитие системы и действительно ли получить информацию о ней невозможно? Вероятно, представление о системе в целом и о предполагаемых (руководством) путях ее развития можно получить посредством семинаров. После этого разбить сложную систему на более простые компоненты, упростить связи между компонентами, предусмотреть независимость компонентов и описать интерфейсы между ними (чтобы изменение одного компонента автоматически не влекло за собой существенного изменения другого компонента), а также возможности расширения системы и "заглушки" для нереализуемых в той или иной версии системы функций. Исходя из подобных элементарных соображений описание того, что предполагается реализовать в информационной системе, уже не кажется столь нереальным. Можно придерживаться классических подходов к разработке информационных систем, один из которых - схема "водопада" (рис. 1 ) - описан ниже. Кратко будут рассмотрены и некоторые другие подходы к разработке информационных систем, где использование элементов, описанных в схеме "водопада", также допустимо. Какого подхода из описываемых ниже придерживаться (и есть ли смысл придумывать собственный подход) - в какой-то мере дело вкуса и обстоятельств.

Рис. 1. Cхема «водопада»

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

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

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

В начало

"Водопад" - схема разработки проекта

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

В начало

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

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

описание выполняемых системой функций;

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

сущности, необходимые для выполнения функций системы;

интерфейсы и распределение функций между человеком и системой;

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

что не будет реализовано в рамках проекта.

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won"t have - отсутствующие функции.

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

В начало

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

функции - информация о событиях и процессах, которые происходят в бизнесе;

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

Двумя классическими результатами анализа являются:

иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);

модель "сущность-связь" (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;

диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;

диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

В начало

ER-диаграммы

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

Рис. 2. Пример ER-диаграммы

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом, являются ключевыми (так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3 ) означает "один", "птичья лапка", слева - "многие", а отношение читается вдоль линии, например "один ко многим". Вертикальная черта означает "обязательно", кружок - "не обязательно", например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рис. 3. Элемент ER-диаграммы

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

Рис. 4. ER-диаграмма рефлексивного отношения

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

Атрибуты сущностей могут быть ключевыми - они выделяются полужирным шрифтом; обязательными - перед ними ставится знак "*", то есть их значение всегда известно, необязательными (optional) - перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными.

В начало

Дуги

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

Рис. 5. Дуга

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям: "для физического лица" и "для юридического лица". Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6 .

Рис. 6. Подтипы (справа) и супертип (слева)

В начало

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа "один к одному" (рис. 7 ) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Рис. 7. Связи «один к одному»

Связи "многие к одному" представлены на рис. 8 .

Рис. 8. Связи «многие к одному»

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

II - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи "многие ко многим" представлены на рис. 9 .

Рис. 9. Связи «многие ко многим»

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

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10 ).

Рис. 10. Рекурсивные связи

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

III - имеет место на ранних этапах. Часто отражает структуру "перечня материалов" (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь "многие ко многим" (рис. 11 ) и ряд рекурсивных связей (рис. 12 ).

Рис. 11. Недопустимые связи «многие ко многим»

Рис. 12. Недопустимые рекурсивные связи

Обязательная связь "многие ко многим" в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

В начало

Диаграммы потоков данных

Логическая DFD (рис. 13 ) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

Рис. 13. Пример DFD

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

позволяют представить систему с точки зрения данных;

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

позволяют представить как автоматизированные, так и ручные процессы системы;

выполняют ориентированное на данные секционирование всей системы.

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

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

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

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например "Клиент". Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

В начало

Диаграммы изменения состояний STD

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14 ). Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний.

Рис.14. Пример DFD

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

В начало

Некоторые принципы проверки качества и полноты информационной модели (источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

В начало

Качество сущностей

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

Список проверочных вопросов для сущности:

Отражает ли имя сущности суть данного объекта?

Нет ли пересечения с другими сущностями?

Имеются ли хотя бы два атрибута?

Всего атрибутов не более восьми?

Есть ли синонимы/омонимы данной сущности?

Сущность определена полностью?

Есть ли уникальный идентификатор?

Имеется ли хотя бы одна связь?

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

Ведется ли история изменений?

Имеет ли место соответствие принципам нормализации данных?

Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?

Не имеет ли сущность слишком общий смысл?

Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

Отсутствуют ли пересечения с другими подтипами?

Имеет ли подтип какие-нибудь атрибуты и/или связи?

Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

Имеется ли исчерпывающий набор подтипов?

Не является ли подтип примером вхождения сущности?

Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

В начало

Качество атрибутов

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

Список проверочных вопросов для атрибута:

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?

Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?

Имеет ли атрибут только одно значение в каждый момент времени?

Отсутствуют ли повторяющиеся значения (или группы)?

Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

Не может ли он быть пропущенной связью?

Есть ли необходимость в истории изменений?

Зависит ли его значение только от данной сущности?

Если значение атрибута является обязательным, всегда ли оно известно?

Есть ли необходимость в создании домена для этого и ему подобных атрибутов?

Зависит ли его значение только от какой-то части уникального идентификатора?

Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Информационная система управления проектами [англ. - Project Management Information System]. Успешная и продуктивная проектная деятельности организации невозможна без применения информационных технологий. С целью автоматизации процессов и консолидации данных управления проектами выступает информационная система управления проектами, которая представляет собой сбалансированный организационно-технологический комплекс программных, технических и информационных средств и инструментов, направленный на реализацию, поддержку и повышение эффективности процессов управления проектами. ИСУП является неотъемлемой частью корпоративной системы управления проектами (КСУП).

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

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

Разнообразие информационных систем управления проектами

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

• Локальные информационные системы управления проектами. В основном предназначаются для малого бизнеса, частных предпринимателей и компаний, в которых практически нет проектной деятельности, за исключением одного - двух небольших проектов. Плюсы таких систем в дешевизне и доступности. В качестве примера можно привести Microsoft Project Standart или Professional, Open Project и д.р.
• Серверные информационные системы управления проектами. Глобальное решение, ориентированное на средний и крупный бизнес, в задачи которого входит автоматизация проектного управления на уровне проекта, программы, портфеля проектов (или нескольких портфелей) и автоматизация процессов проектного офиса. Данные системы сильно распространенны в мире, и большинство ведущих компаний используют именно их, для управления проектами. Минусы в дороговизне внедрения и сопровождения, необходимость укомплектовывать штат компании. Лидерами таких систем являются Oracle Primavera, HP Project and Portfolio Management Center, Enterprise Project Management Solutions. Кстати многие из этих систем уже сегодня предоставляют решение на основе интернет технологий, как описано ниже.
• Информационные системы управления проектами на основе интернет технологий. Современный подход к предоставлению услуг, по функционалу не отличающийся от серверных решений, но позволяющий компаниям не внедрять у себя это решение, закупая много специального оборудования (компьютеры, сервера) и формируя штат персонала поддержки и сопровождения, а использовать современный подход - облачные технологии на основе которых сторонняя компания удаленно предоставляет необходимый функционал, что позволяет использовать мощности поставщика услуг и снижает затраты на внедрение и сопровождение. Минусы заключаются в том, что Вы передаёте всю информацию по проектной деятельности сторонней компании, которая отвечает за их безопасность и эти системы на сегодняшний день не столь функциональны, нежели серверные решения, а также они менее настраиваемые. Как пример можно привести такие решения - IBN, COMINDWORK, МЕГАПЛАН.

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

1

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

информационная система

структура

методика

инвестиционный проект

административная структура

1. Брыкин И.М., Беклемишев А.В. Оценка, выбор и анализ инвестиционных проектов. – М.: ООО «Международная Медиа Группа», 2011. – 47 с.

2. Бэйли Д.В., Шарп У.Ф., Александер Г.Д. Инвестиции. – М.: ИНФРА-М, 2012. – 1028 с.

3. Виленский П.Л., Лившиц В.Н., Смоляк С.А. Оценка эффективности инвестиционных проектов. Теория и практика: Учеб. Пособие. – М.: Дело, 2008. – 888 с.

4. Кравченко Т.К., Пресняков В.Ф. Инфокоммуникационные технологии управления предприятием – М.: ГУ ВШЭ, 2003. – 272 с.

5. Липсиц И.В., Коссов В.В. Инвестиционный анализ. Подготовка и оценка инвестиций в реальные активы. – М.: ИНФРА-М, 2014. – 320 с.

6. Светлов Н.М., Светлова Г.Н. Информационные технологии управления проектами – М.: ИНФРА-М, 2012. – 144 с.

7. Шуремов Е. Компьютерный анализ бизнеса. // Мир ПК. – 1998. – № 1. – С. 80–83.

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

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

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

Структура информационной системы

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

Анализ финансового состояния предприятия, в том числе в динамике;

Анализ финансовой части бизнес-плана проекта;

Анализ влияния кредита на финансовое состояние предприятия;

Учет приоритетов города в процессе анализа проекта;

Сравнительный анализ проектов нескольких предприятий;

Прогноз развития предприятия и возврата кредитов.

Исходя из особенностей и характера поставленных задач, разработана структурная схема системы анализа, представленная на рисунке.

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

Бухгалтерского баланса и дополнительных документов по балансу;

Финансовой части бизнес-плана проекта;

Дополнительной информации, требующейся для учета приоритетов административного органа управления.

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

Структура основной части системы направлена на реализацию особенностей анализа инвестиционных проектов.

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

«Модуль расчета финансовых показателей» осуществляет расчет финансовых коэффициентов.

Структурная схема информационной системы анализа инвестиционных проектов

«Модуль анализа проекта и визуализации результатов» осуществляет представление результатов анализа аналитическими, графическими и табличными способами.

«Модуль генерации отчетов» связан со стандартными программными средствами и предназначен для подготовки отчетных материалов.

Экспертная система призвана оказывать помощь при анализе полученных результатов.

Методика анализа инвестиционных проектов

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

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

Таким образом, имеется L-групп исходных показателей , где и L-групп относительных показателей , где , l - номер группы, а kl - порядковый номер показателя в группе.

На основе первичных показателей формируются Q-групп вторичных показателей , где q = 1, Q, , а mq - порядковый номер показателя в q-ой группе. Эти показатели назовем коэффициентами.

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

где j - характеризует номер измерений показателя или коэффициента.

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

Тогда I = J + 1.

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

В процессе анализа предпринимательского проекта решаются по крайней мере три принципиальные задачи:

а) оценка возможности возврата кредита рассматриваемым предприятием и, следовательно, решение о его включении в список потенциально пригодных для кредитования;

б) оценка возможности кредитования, исходя из приоритетов администрации;

Эти задачи решаются в рамках многоуровневого анализа коэффициентов и показателей.

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

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

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

На следующем этапе формируется оценка проекта по пункту

б) Для учета интересов администрации вводится дополнительная группа показателей {fh} и условий {χh}, где h = 1,H. Эти показатели могут быть рассчитаны или представлены предприятием. Если предприятие не соответствует критериям, оно исключается из группы потенциально кредитуемых.

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

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

где ζ - номер сценария;

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

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

Веса меньше 1, суммы весов каждого набора по всей выборке равны 1.

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

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

где , если рост коэффициента характеризует улучшение финансового состояния предприятия и

д) чем выше R ζ s, тем выше рейтинг s-го предприятия в ζ -ом сценарии оценки.

Нормировкой {R ζ s} по , можно расставить предприятия в порядке возрастания или убывания их рейтинга. Рейтинг по показателям , и fh можно проводить отдельно.

Заключение

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

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

Библиографическая ссылка

Клевцов С.И., Клевцова А.Б. МОДЕЛЬ ИНФОРМАЦИОННОЙ СИСТЕМЫ АНАЛИЗА ИНВЕСТИЦИОННЫХ ПРОЕКТОВ ДЛЯ АДМИНИСТРАТИВНЫХ СТРУКТУР // Фундаментальные исследования. – 2016. – № 12-1. – С. 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (дата обращения: 26.04.2019). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания» А почему бы и нет? Это хороший пример. Проект везде проект: плюс-минус те же стадии, та же схема управления, документооборот, работа с рисками, контроль качества и так далее. Везде есть требования и к оборудованию, и к помещениям, и к ПО. Вы спросите, какие могут быть требования к помещениям в Информационной Системе? Очень просто: расположение рабочих мест операторов, сервера - и тем и другим потребуется кондиционер. Вот уже и требования к помещениям. И вряд ли нынче кто-то сомневается, нужно ли больнице ПО. Если вы хотите идти в ногу со временем, перед вами встанет задача создать автоматизированное лечебное учреждение с электронными медицинскими картами, где врачи делают осмотр с планшетами, а, например, санитарки отмечают вымытый туалет не на листике, а в телефоне. Требований к ПО в данном случае будет предостаточно. А как только потребуется ПО, появится необходимость установить сервера, куда-то посадить админа и операторов. Все взаимосвязано.

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

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

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

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

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

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

Информационная система (разве это только ПО?)

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

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

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

То есть, ИС в первую очередь - это люди, плюс технология, помогающая автоматизировать их деятельность, и никак не наоборот.

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

Представим, что вы строительная организация, к вам приходит заказчик и просит в таком-то месте построить больницу. Вы сразу побежите кирпичи класть или…? Если смотреть на то, как зачастую создаются Информационные Системы, то так и есть: исполнители тут же начинают «мешать бетон и закупать стеклопакеты». Мол, выйдет не так - перестроим! Будем перестраивать, пока не добьемся нужного результата.

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

Без проекта всегда так, даже если этого не видно

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

И почему такое не изучают в первом классе?

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

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

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

Видно хорошо, но только малую часть

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

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

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

Итак, допустим вы - проектант. К вам приходит заказчик, «посланный» ответственными строителями. Заказчик, естественно, просит вас разработать проект больницы. Вы бежите к кульману и… Ну ладно, это уже древность - запускаете ArchiCAD и чертите.

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

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

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

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

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

На данном этапе необходимо выбрать общие технические решения, с помощью которых могут быть выполнены требования, составленные на предыдущем этапе. Будет ли это веб-приложение или нативное, толстый клиент или тонкий, централизованная база или распределенная, реляционная СУБД или noSQL, монолит или микросервисы, Java или Python. Часто данные вопросы забывают обсудить вовремя, а потом оказывается, что кто-то из программистов самостоятельно выбрал определенный инструмент, а в конце концов данное решение не позволяет достичь поставленной цели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одни люди двумя руками за Agile (или иные «гибкие» методы разработки), другие резко против. У автора же статьи свое мнение: Agile очень хорош, но к месту. А используют его обычно не по назначению.

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

Заказчик думает: и сколько меня еще будут по кругу за нос водить?

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

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

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

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

Книжек на эту тему много. Толстых и не очень. Но книжка - это всегда ЧУЖОЙ опыт. А у вас другой характер, отличная ситуация и проект. Есть такая система ТРИЗ - теория решения изобретательских задач. Ее автор, Альтшуллер, пытается объяснить шаги, которые нужно предпринять, чтобы изобрести что-либо. Получается? Как правило, нет. Принципы излагаются интересные, полезные, но единого шаблона по изобретению не выходит. Каждый человек думает и творит по-своему, да и невозможно этому научить, можно только научиться. Чужой опыт использовать надо, глупо не использовать, но он должен быть пережит (переработан) вами, переложен на ВАШЕ мышление. Скопировать чудо не удастся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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