Смекни!
smekni.com

Методические указания для самостоятельной работы студентов Дата разработки 15. 07. 2008 (стр. 19 из 23)

16.1.1. Возможности компании

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

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

16.1.2. Технические критерии

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

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

16.1.3. Организационные критерии

Среди них наиболее существенными являются:

  • масштабы и рамки проведения бизнес-моделирования;
  • необходимость и сложность внедрения управленческих изменений;
  • потребность во внедрении методов управления проектами;
  • предполагаемое расширение штата и функций ИТ-отдела;
  • уровень привлечения сторонних организаций.

16.1.4. Риски

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

  • правильность выбора системы (управленческого ПО);
  • риск незавершенности проекта внедрения;
  • риски качества продуктов проекта;
  • риски выхода за рамки проекта и другие.

Анализ вариантов развития по оставшимся группам критериев (

16.1.5. Временные рамки

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

16.1.6. Бюджетные рамки

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

17. Организация управления для различных этапов организации ИТ и ИС : разработка, внедрение, эксплуатация, развитие (модернизация)

В жизненном цикле выделяют следующие стадии [1]:

17.1. Предпроектное обследование

Сбор материалов для проектирования:

    • формирование требований;
    • изучение объекта автоматизации;
    • выбор и разработка варианта концепции системы.

    Анализ материалов и разработка документации:

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

      17.2. Эскизное, техническое – предварительное проектирование:

        • выбор проектных решений по всем аспектам разработки информационной системы;
        • описание всех компонентов информационной системы;
        • оформление и утверждение технического проекта.

        17.3. Рабочее - детальное проектирование:

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

          17.4. Разработка информационной системы

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

            17.5. Ввод информационной системы в эксплуатацию

              • ввод в опытную эксплуатацию технических средств;
              • ввод в опытную эксплуатацию программных средств;
              • обучение и сертифицирование персонала;
              • проведение опытной эксплуатации всех компонентов и системы в целом;
              • сдача в эксплуатацию и подписание актов приемки-сдачи работ.

              17.6. Эксплуатация информационной системы

                • повседневная эксплуатация;
                • сопровождение программных, технических средств и всего проекта.

                18. Состав и содержание работ на этапе разработки ИТ и ИС

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

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

                18.1. Основные участники разработки

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

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

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

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

                18.2. Документирование этапов разработки

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

                Качество документации должно отвечать следующим критериям:

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

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

                Исходные коды

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