27Средства разработки по
Основные цели разработки ПО:
- определение структуры кода на основе реализуемых подсистем, организованных по уровням;
- реализация классов и объектов в виде модулей (исходных, двоичных, исполняемых файлов и др.);
- тестирование разработанных модулей;
- интеграция результатов работы отдельных программистов (или групп) в рабочую систему.
Для ведения непосредственной разработки IBM Rational предлагает целый набор специализированных инструментальных средств:
- IBM Rational Application Developer
- IBM Rational Web Developer
- IBM Rational XDE Developer
22Типы структур управления разработкой ИС
Структуры проектной группы
Открытая организационная структура проектной группы отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива разработчиков является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на отдельных этапах распределяются между разработчиками в соответствии с их знаниями, опытом и способностями.
Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего административное и техническое руководство. Он же является основным посредником между группой, заказчиком проекта и внешними организациями.
Децентрализованная организационная структура проектной группы имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью разработчиков (свыше 10 человек), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач.
25Расчет экономической эффективности
Экономико-организационная часть рабочего проекта содержит
уточненный перечень задач, решаемых каждой подсистемой, с указанием периодичности и сроков их решения; инструкции каждому должностному лицу с описанием действий при нормальном режиме функционирования системы и при его нарушениях; порядок и правила использования входных документов и маршруты их движения.
Расчет экономической эффективности проводится на основе уточненных сметно-финансовых расчетов на создание системы. Мероприятия по подготовке объекта и внедрению системы включают общий перечень работ, наименование подразделений и ответственных исполнителей, срок исполнения и формы завершения отдельных этапов.
Информационная часть рабочего проекта включает материалы с перечнем показателей, используемых в задачах различных подсистем; описание порядка формирования массивов информации; описание методов внесения изменений в информацию и методов организации контроля информации; перечень показателей, выдаваемых по запросу аппарата управления.
Кроме того, приводятся альбомы документов и рабочие инструкции: по формированию исходных данных для решения задач, по организации массивов информации, внесению в них изменений, по хранению и обновлению информации.
Математическая часть рабочего проекта содержит уточнение в составе экономико-математических моделей; описание методов, алгоритмы и программы решения задач; описание методов организации массивов информации; выбранную систему программирования; используемую операционную систему; библиотеку стандартных программ и инструкции для их использования; эталоны программ для решения задач и для работы с НСИ. Техническая часть рабочего проекта предусматривает определение технических средств (тип ЭВМ, периферийные устройства, средства связи и передачи данных); описание технологического процесса обработки данных; расчет и составление графика загрузки комплекса технических средств; описание режима функционирования комплекса технических средств.
Проектная документация, включая техническое задание, технические и рабочие проекты, оформляется в соответствии с требованиями Единой системы конструкторской документации (ЕСКД).
Рабочее проектирование заключается в разработке материалов, обеспечивающих эксплуатацию автоматизированной системы обработки информации.
Рабочий проект — это техническая документация, утвержденная в установленном порядке, содержащая уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности автоматизированной системы управления и уточненный перечень мероприятий по подготовке объекта к внедрению.
Рабочий проект разрабатывается на основе технического проекта, утвержденного заказчиком.
На этапе рабочего проектирования заказчик должен закончить работы по подготовке объекта к внедрению системы, подготовить помещения для установки компьютеров, организовать учебу работников всех звеньев организационной структуры, разместить заказы на изготовление нестандартного оборудования. Разработчиками на этом этапе создания системы уточняется сетевой график выполнения рабочего проекта, проводятся экспериментальные исследования для изыскания путей реализации принятых проектных решений, обосновываются дополнительные проектные решения, разрабатывается технологический процесс сбора и обработки информации, составляется рабочая документация, уточняются расчеты экономической эффективности системы.
В состав рабочей документации проекта входят документы:
1. Пояснительная записка.
2. Функциональная и организационная структура.
3. Должностные инструкции.
4. Инструкция по заполнению входных оперативных документов.
5. Инструкция по использованию выходных документов.
6. Инструкция по организации и ведению нормативно-справочной информации.
7. Инструкция по организации хранения информации в архиве.
8. Инструкция по подготовке информации к вводу в ПК.
9. Расчет экономической эффективности системы.
10. Мероприятия по подготовке объекта к внедрению.
11. Ведомость документов.
26Нормирование труда
Информационная отрасль имеет свои особенности нормирования, стимулирования и оплаты труда.
Техническое обслуживание:
составления технических средств по комплектованию;
сборка, монтаж, установка, подключение и наладка аппаратных средств и локальных сетей у заказчика;
ремонт, тестирование, апгрейд (модернизация) технических средств, текущее техническое обслуживание
Специалисты, его обеспечивают, имеющих соответствующее образование и опыт практической работы О нормировании их труда вряд ли целесообразно говорить, что же касается оплаты, то она зависит от уровня квал лификации, системы оплаты, принятой на фирме, и условий контрактов и договоров с заказчиками Относительно текущего технического обслуживания, то есть парадокс: тому, кто большую часть рабочего времени «сидит, сложа руки, а техника сама работает », надо платить больше чем тому, кто целыми днями занимается ремонтом, потому что именно это является свидетельством, что он не очень квалифицированный специалистць.
Программирование Проблема нормирования труда программистов очень актуальной, когда ее результатом были тексты готовых программ, написанные на определенном языке программирования, и количество строк этой программы определяла конечный и объем работы, а поделен на количество рабочих дней - давал уровень производительности труда Вообще, во всех странах считалось, что в среднем 10-15 операторов на рабочий день - это достаточно высокий уровень производительности труда программиста.
Создание норм и нормативов затрат труда для программирования - достаточно сложный процесс, прежде всего потому что программирование - творческая работа, а также потому что в программировании одной задачи могут принимать в участие специалисты различных профессий и категорий, а именносаме:
научные работники;
математики;
инженеры-технологи;
экономисты;
техники;
операторы
Кроме того, производительность труда при программировании зависит от многих факторов, учесть которые сложно Это:
логическая сложность программируемой задачи;
квалификация программиста;
математическое обеспечение ЭВМ
Основными методами нормирования является опытно-статистический, когда нормы времени устанавливаются на основе отчетных данных о затратах времени в прошлом на выполнение аналогичных работ по программированию Типовые нормы ча асу на программирование задач для ЭВМ утвержден в 1986.
Осуществить оценку и нормирования труда руководителей ИТ-подразделений, системных аналитиков, программистов и других высококвалифицированных специалистов значительно сложнее чем техников или операторов Для оценки пра аци этой категории рабочих можно использовать такие показатели:
соблюдение сроков разработки систем и программ;
изучения и практическое использование новых языков и методов программирования;
создания четких инструкций, облегчающих использование программ;
одобрения работы со стороны пользователей
Вопросы нормирования труда при программировании очень важно для планирования, учета, анализа и оперативного управления деятельностью ВЦ Нормы времени охватывают работы, выполняемые специалистами на таких стаде иях разработке проектных материалов:
техническое задание;
эскизный проект;
технический проект;
рабочий проект;
внедрения
Нормы времени рассчитаны зависимости от факторов, влияющие на трудоемкость разработки проекта:
количество разновидностей форм входной информации;
количество разновидностей форм выходной информации;
степень новизны комплекса задач (задачи);
сложность алгоритма;
вид используемой информации (переменная информация, НСИ, БД);
сложность контроля входной и выходной информации;
использования ТПР (ППП), типовых проектов, типовых программ, стандартных модулей
Исходя из трудоемкости стадий разработки ПО ОТ, оценивается количество специалистов или срок, необходимый для реализации стадий его разработки
Подбором количества разработчиков на разных стадиях достигают желаемого срока разработки ПО ОТ
Сейчас технологии обработки информации, технологии программирования настолько разнообразны, настолько усовершенствованы, что невозможно сопоставлять работу программистов в различных средах, можно делать сравнения я только в аналогичных средах и устанавливать сроки разработки программных продуктов исходя из статистических данных и практического опыта Это касается программистов среднего уровня, то есть ис онавцив Высшая квалификация в программировании определяется теми принципиально новыми идеями, которые дают развитие новым направлениям в этой области Это было и остается творческой составляющей деятельности программиста, опл ату которой невозможно нормироватьати.
23. Документы управления разработкой
Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)
Формализованное описание информации в системе. Формализация информации в ИС является её кодированием с использованием классификаторов. Классификатор — это документ, с помощью которого осуществляется формализованное описание информации в ИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения. По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы. Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества. Общегосударственные (общесистемные) классификаторы, обязательны для организации процессов передачи и обработки информации между экономическими системами государственного уровня внутри страны. Отраслевые классификаторы используют для выполнения процедур обработки информации и передачи ее между организациями внутри отрасли. Локальные классификаторы используют в пределах отдельных предприятий. Каждая система классификации характеризуется следующими свойствами:
Диаграммы переходов состояний (SDT)
SDT демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий (извне).
В диаграммах такого вида узлы соответствуют состояниям динамической системы, а дуги — переходу системы из одного состояния в другое. Узел, из которого выходит дуга, является
начальным состоянием, узел, в который дуга входит, — следующим.
Дуга помечается именем входного сигнала или события, вызывающего переход, а также сигналом или действием, сопровождающим переход. Условные обозначения, используемые при построении диаграмм переходов состояний, показаны на рис. 3.19.
На рис. 3.20 представлена диаграмма переходов состояний
программы, активно не взаимодействующей с окружающей средой, которая имеет примитивный интерфейс, производит некоторые вычисления и выводит простой результат [1].
На рис. 3.21 представлена диаграмма переходов торгового автомата, активно взаимодействующего с покупателем [55].
Диаграммы потоков данных (DFD)
Такая диаграмма состоит из трех типов узлов: узлов обработки данных, узлов хранения данных и внешних узлов, представляющих внешние по отношению к используемой диаграмме
источники или потребители данных. Дуги в диаграмме соответствуют потокам данных, передаваемых от узла к узлу. Они помечены именами соответствующих данных. Описание процесса,
функции или системы обработки данных, соответствующих узлу диаграммы, может быть представлено диаграммой следующего уровня детализации, если процесс достаточно сложен [1, 53].
Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна — Сарсона (табл. 3.4).
Первым шагом при построении иерархии диаграмм потоков данных является построение контекстных диаграмм, показывающих, как система будет взаимодействовать с пользователями
и другими внешними системами. При проектировании простых систем достаточно одной контекстной диаграммы, имеющей звездную топологию, в центре которой располагается основной
процесс, соединенный с источниками и приемниками информации.
Для сложных систем строится иерархия контекстных диаграмм, которая определяет взаимодействие основных функциональных подсистем проектируемой системы как между собой, так и с внешними входными и выходными потоками данных и внешними объектами. При этом контекстная диаграмма верхнего уровня содержит набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют содержимое и структуру подсистем.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных и отсутствие информационных связей с другими объектами.
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация с помощью диаграмм потоков данных, при этом необходимо соблюдать следующие правила [53]:
• правило балансировки. Означает, что при детализации подсистемы можно использовать только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми она имеет информационную связь на родительской диаграмме;
• правило нумерации. Означает, что при детализации подсистем должна поддерживаться их иерархическая нумерация. Например, подсистемы, детализирующие подсистему с номером 2, получают номера 2.1, 2.2, 2.3 и т. д.
При построении иерархии диаграмм потоков данных переходить к детализации процессов следует только после определения структур данных, которые описывают содержание всех потоков
и накопителей данных. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что соответствующие компоненты могут отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает, что компонент может повторяться в структуре некоторое указанное число раз. Для каждого элемента данных может Указываться его тип (непрерывный или дискретный). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значений, точность представления и форма Физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
Построенную модель системы необходимо проверить на полноту и согласованность. В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно
описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и
накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
В соответствии с вышесказанным процесс построения модели разбивается на следующие этапы [39]:
1. Выделение множества требований в основные функциональные группы — процессы.
2. Выявление внешних объектов, связанных с разрабатываемой системой.
3. Идентификация основных потоков информации, циркулирующей между системой и внешними объектами.
4. Предварительная разработка контекстной диаграммы.
5. Проверка предварительной контекстной диаграммы и внесение в нее изменений.
6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
7. Проверка основных требований контекстной диаграммы.
8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
9. Проверка основных требований по DFD соответствующего уровня.
10. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.
Пример 3.2. Разработаем иерархию диаграмм потоков данных программы сортировки одномерных массивов.
Для начала построим контекстную диаграмму, для чего определим внешние сущности и потоки данных между программой и внешними сущностями. Внешней сущностью по отношению к программе является Пользователь. Он выбирает метод сортировки и вводит исходные данные, а затем получает от программы описание выбранного метода и отсортированный массив. На рис. 3.29 представлена контекстная диаграмма данной программы.
После детализации получилось три процесса: Меню, Сортировка, Вывод результата. Для хранения описаний алгоритмов служит Хранилище алгоритмов. Теперь определим потоки данных.
Детализирующая диаграмма потоков данных изображена на рис. 3.30. Как мы видим, она несколько отличается от функциональной диаграммы (см. рис. 3.28), например, на ней показано хранилище данных для хранения описаний алгоритмов. Это отличие является важным при проектировании баз данных.
16. Архитектуры информационных систем: монолит, файл-сервер, клиент-сервер, многоуровневая, интранет/экстранет, сервисно-ориентированная
В любой информационной системе можно выделить необходимые функциональные компоненты, которые помогают понять ограничения различных архитектур информационных систем.
Архитектура файл-сервер только извлекает данные из файлов так, что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к сети.
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.
В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:
нижний уровень представляет собой приложения клиентов, имеющие программный интерфейс для вызова приложения на среднем уровне;
средний уровень представляет собой сервер приложений;
верхний уровень представляет собой удаленный специализированный сервер базы данных.
Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер.
В развитии технологии Интернет/экстанет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер — сервер приложений — сервер баз данных — сервер динамических страниц — web-сервер.
По характеру хранимой информации БД делятся на фактографические и документальные. Если проводить аналогию с описанными выше примерами информационных хранилищ, то фактографические БД — это картотеки, а документальные — это архивы. В фактографических БД хранится краткая информация в строго определенном формате. В документальных БД — всевозможные документы. Причем это могут быть не только текстовые документы, но и графика, видео и звук (мультимедиа).
Автоматизированная система управления (АСУ) - это комплекс технических и программных средств, совместно с организационными структурами (отдельными людьми пли коллективом), обеспечивающий управление объектом (комплексом) в производственной, научной или общественной среде.
Выделяют информационные системы управления образования (Например, кадры, абитуриент, студент, библиотечные программы). Автоматизированные системы для научных исследований (АСНИ), представляющие собой программно-аппаратные комплексы, обрабатывающие данные, поступающие от различного рода экспериментальных установок и измерительных приборов, и на основе их анализа облегчающие обнаружение новых эффектов и закономерностей. Системы автоматизированного проектирования и геоинформационные системы.
Систему искусственного интеллекта, построенную на основе высококачественных специальных знании о некоторой предметной области (полученных от экспертов - специалистов этой области), называют экспертной системой. Экспертные системы - один из немногих видов систем искусственного интеллекта - получили широкое распространение, и нашли практическое применение. Существуют экспертные системы по военному делу, геологии, инженерному делу, информатике, космической технике, математике, медицине, метеорологии, промышленности, сельскому хозяйству, управлению, физике, химии, электронике, юриспруденции и т.д. И только то, что экспертные системы остаются весьма сложными, дорогими, а главное, узкоспециализированными программами, сдерживает их еще более широкое распространение.
Экспертные системы (ЭС) - это компьютерные программы, созданные для выполнения тех видов деятельности, которые под силу человеку-эксперту. Они работают таким образом, что имитируют образ действий человека-эксперта, и существенно отличаются от точных, хорошо аргументированных алгоритмов и не похожи на математические процедуры большинства традиционных разработок.
Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработкепрограммного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированнымпротоколам.
Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini,CORBA, на основе REST).
Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование имногократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемостисоздаваемых систем.