Файл: GOSY.doc

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

1. фаза анализа и планирования требований;

2. фаза проектирования;

3. фаза построения;

4. фаза внедрения.

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

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

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

1. общая информационная модель системы;

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

3. точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

4. построенные прототипы экранов, отчетов, диалогов.

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

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

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

1. определяется необходимость распределения данных;

2. производится анализ использования данных;

3. производится физическое проектирование базы данных;

4. определяются требования к аппаратным ресурсам;

5. определяются способы увеличения производительности;

6. завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Вопрос 2 – Облачные технологии

Облачные технологии сегодня в моде. Но что они из себя представляют? Этот вопрос можно часто услышать от многих людей. Некоторые аналитики и поставщики облачных технологий определяют это понятие узко, в основном как виртуальные сервисы доступные через Интернет. Другие обьясняют это понятие очень широко, утверждая, что используя их вы становитесь потребителем множества продуктов за пределами межсетевого экрана (в облаке), включая обычный аутсорсинг.

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

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

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

2. Utility computing Идея не нова, но эта форма облачных технологий приобрела новую жизнь с Amazon.com, Sun, IBM и другими, предлагающими в настоящее время виртуальные серверы вычислительных ресурсов по принципу коммунальных услуг, доступ к которым клиент может получить в любое время. Выгода для Вас как клиента в том, что вы платите за вычислительные ресурсы и программное обеспечение только тогда, когда они вам действительно нужны. Концепция utility computing (UC) — предоставление вычислительных ресурсов по принципу коммунальных услуг - позволяет добиться недостижимой ранее эффективности.

3. Среда разработки как сервис Другой вариант SaaS, эта форма облачных технологий обеспечивает среду разработки как сервис. Вы создаете собственные приложения, которые работают на инфраструктуре провайдера и доставляются пользователям через Интернет с серверов провайдера. Как и Legos, эти услуги ограничиваются дизайном поставщика и его возможностями, так что вы конечно не получаете полную свободу, но вы получите предсказуемость и предварительную интеграцию. Пример подобного сервиса Salesforce.com, Coghead и новый Google App Engine.

4. MSP (управляемые услуги) Одна из старейших форм облачных технологий, включает в себя процесс управления несколькими взаимосвязанными программами. В основном этим сервисом пользуются поставщики IT, а не конечные пользователи. MSP это управление программами, такими как антивирусная служба, электронная почта или служба мониторинга приложений. Например, услуги по безопасности предоставляемые SecureWorks, IBM и Verizon так-же попадают в эту категорию, поскольку предоставляют услуги на основе анти-спама Postini, недавно приобретенного Google.

5. Service commerce platforms Эта услуга гибрид SaaS и MSP, сервис входящий в облачные технологии предлагает услуги из центра, с которым пользователи в дальнейшем взаимодействуют. Данный сервис наиболее распространен в условиях торговли. Позволяет пользователям например заказать билеты для путешествия или секретарские услуги из общей платформы, которая затем координирует предоставление услуг и цен в допустимых пределах заданных пользователем. Работает этот сервис как автоматизированное бюро обслуживания. Для примера можно привести Rearden Commerce и Ariba.

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

Вопрос 3 – Создать документ следующего вида

Экзаменационный билет № 23

Вопрос 1 - Базовые стандарты управления корпорацией Новая экономическая ситуация ставит перед предприятиями ряд задач, которые ранее ими не рассматривались. Среди наиболее важных задач, стоящих перед промышленными предприятиями в современных условиях, можно выделить:

1. повышение конкурентной борьбы;

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

3. необходимость оперативного принятия решений в сложной экономической ситуации;

4. укрепление связей между поставщиками, производителями и покупателями.

В конкурентной борьбе побеждает только тот, кто быстрее других реагирует на изменения в бизнесе и принимает более верные решения. Именно информационные технологии помогают руководителям промышленных предприятий в решении этих сложных задач. Страны рыночной экономики имеют большой опыт создания и развития информационных технологий для промышленных предприятий. В наши дни КИС строятся на стандартах ERP, CSRP и ERPII. К КИС или, как их еще называют, к корпоративным управленческим системам EAS (Enterprise Application Suite – набор приложений масштаба предприятия) относятся системы стандартов MPS, MPR , MPR II, ERP, ERP II и CSRP. Эволюционный путь этих базовых стандартов представлен на рис. 3 Исходным стандартом, появившимся в конце 50-х – начале 60-х годов, был стандарт ^ MPS (Master Planning Scheduling – управление календарным планированием), предназначенный для составления основного плана производства. На основании данных о состоянии спроса вырабатывались планы выпуска конечной продукции. С целью оптимального управления производством в середине 60-х годов были сформулированы принципы управления материальными запасами предприятия. Эти принципы легли в основу систем класса MRP (Material Requirement Planning - планирования материальных потребностей). Эти системы могут быстро подсчитать возможность выполнения нового заказа к нужному сроку при текущей загрузке производства. При условиях невозможности выполнения данного заказа к конкретному сроку, система способна ответить на вопрос, во что обойдется заказчику выполнение нового заказа, если он все же на сроке настаивает. Затем появились системы класса ^ MRPII (Manufacturing Resource Planning - планирование производственных ресурсов), основная суть которых сводится к тому, что прогнозирование, планирование и контроль производства осуществляется по всему циклу, начиная от закупки сырья и заканчивая отгрузкой товара потребителю. В общем случае они обеспечивают решение задач планирования деятельности предприятия в натуральных единицах, финансовое планирование в денежном выражении. Следующим этапом в развитии КИС стало появление с конца 80-х годов систем класса ^ ERP (Enterprise Resource Planning - планирование ресурсов предприятия). Эти системы охватывают всю финансово-хозяйственную и производственную деятельность предприятия. К ним предъявляются такие требования как: централизация данных в единой базе, режим работы близкий к реальному времени, сохранение общей модели управления для предприятий любых отраслей, поддержка территориально распределенных структур, работа в широком круге аппаратно-программных платформ и СУБД. Другими важными требованиями к ERP системам являются возможность применения графики, поддержание архитектуры типа “клиент-сервер” и реализации их как открытых систем. При правильном внедрении и эксплуатации таких систем, эффективность бизнес-процессов предприятия повышается, что дает конкурентное преимущество для дальнейшего развития. Однако, занимаясь улучшением внутренней структуры, предприятие не повышает степени эффективности взаимодействия с контрагентами. Следующий этап развития КИС ориентирован на интеграцию деятельности заказчиков и партнеров предприятия в его внутреннюю систему и называется ERPII (Enterprise Resource and Relationship Processing – обработка данных по ресурсам и взаимоотношениям предприятия). Internet предоставляет возможность предприятию взаимодействовать со всеми его контрагентами в совершенно новой среде, позволяющей контактировать напрямую с потребителем по типу B2C (Business-to-Consumer – “бизнес–клиент”) или/и партнерами по бизнесу по типу B2B (Business-to-Business – “бизнес-бизнес”). Для того чтобы ERPII система была применима для электронной коммерции и бизнеса, необходимо создать приложения по управлению связями с заказчиком CRM (Customer Relationship Management – управление взаимоотношениями с клиентом), а также дополнительное программное обеспечение (ПО) промежуточного слоя. Такое ПО назвали EAI (Enterprise Application Integration - интеграция приложений масштаба предприятия). EAI обеспечивает следующие функции: