Министерство образования и молодежной политики Ставропольского края

ГБПОУ «Ставропольский региональный многопрофильный колледж»

 

 

 

 

 

 

 

 

 

 

 

УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС

 

ПО МДК 03.02 Инструментальные средства разработки

 программного обеспечения

 

 

 

 

ДЛЯ СТУДЕНТОВ ОЧНОЙ ФОРМЫ ОБУЧЕНИЯ

Специальности 230115 Программирование в компьютерных системах

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ставрополь, 2016

Составитель: Сапрунова А.А., преподаватель ГБПОУ «Ставропольский региональный многопрофильный колледж»

 

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения составлен в соответствии с требованиями к минимуму результатов освоения дисциплины, изложенными в Федеральном государственном стандарте среднего профессионального образования по специальности 230115 Программирование в компьютерных системах, утвержденном приказом Министерства образования и науки РФ.

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения (далее МДК 03.02)  входит в профессиональный  цикл  и  является частью основной профессиональной образовательной программы ГБПОУ «Ставропольский региональный многопрофильный колледж» г. Ставрополя  по специальности  230115 Программирование в компьютерных система.

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения адресован студентам очной формы обучения.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

СОДЕРЖАНИЕ

 

Наименование разделов	стр.
1. Введение	6
2. Образовательный маршрут	8
3. Содержание дисциплины Раздел 3.  Проектирование программного обеспечения с использованием специализированных программных пакетов Тема 3.1 Проектирование процесса разработки программного продукта Тема 3.2 Использование основных методологий процессов разработки ПО Тема 3.3 Инструментальные средства отладки и тестирования
4. Контроль и оценка результатов освоения учебной дисциплины	49
5 Глоссарий	50
6. Информационное обеспечение дисциплины	55

Уважаемый студент!

 

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

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

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

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

Основные понятия, используемые при изучении содержания МДК, приведены в глоссарии.

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

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

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

По  итогам изучения МДК 03.02 Инструментальные средства разработки программного обеспечения проводится экзамен

 Экзамен: В зачетную книжку выставляется оценка полученная на экзамене.  Допуск у экзамену  выставляется на основании оценок за практические и лабораторные работы и точки рубежного контроля. 

В результате освоения МДК Вы должны уметь:

·          владеть основными методологиями процессов разработки программного обеспечения;

·        использовать методы для получения кода с заданной функциональностью и степенью качества.

В результате освоения МДК Вы должны знать:

·          модели процесса разработки программного обеспечения;

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

·          основные подходы к интегрированию программных модулей;

·          основные методы и средства эффективной разработки;

·          концепции и реализации программных процессов;

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

·          методы организации работы в коллективах разработчиков программного обеспечения;

·          стандарты качества программного обеспечения;

·          методы и средства разработки программной документации

В результате освоения дисциплины у Вас должны формироваться общие компетенции (ОК):

 

Название ОК	Результат, который Вы должны получить после изучения содержания дисциплины
ОК 1.  Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.	-    демонстрация интереса к будущей профессии
ОК 2. Организовывать собственную деятельность, выбирать типовые методы и способы выполнения профессиональных задач, оценивать их эффективность и качество.	-    выбор и применение методов и способов решения профессиональных задач -    оценка эффективности и качества выполнения
ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.	-    решение стандартных и нестандартных профессиональных задач в области разработки программных модулей
ОК 4. Осуществлять поиск и использование информации, необходимой для эффективного выполнения профессиональных задач, профессионального и личностного развития.	-    эффективный поиск необходимой информации; -    использование различных источников, включая электронные
ОК 5. Использовать информационно-коммуникационные технологии в профессиональной деятельности.	-    разрабатывать, программировать  программные модули
ОК 6. Работать в коллективе и в команде, эффективно общаться с коллегами, руководством, потребителями.	-    взаимодействие с обучающимися, преподавателями и мастерами в ходе обучения
ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), за результат выполнения заданий.	-    самоанализ и коррекция результатов собственной работы
ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.	-    организация самостоятельных занятий при изучении профессионального модуля
ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной деятельности.	-    анализ инноваций в области интеграции программных модулей
ОК 10. Исполнять воинскую обязанность, в том числе с применением полученных профессиональных знаний (для юношей).	-    решение ситуативных задач, связанных с использованием профессиональных компетенций

 

            В таблице приведены профессиональные компетенции, к освоению которых готовит содержание дисциплины.

 

Название ПК	Результат, который Вы должны получить после изучения содержания дисциплины
ПК 1. Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения..	-Грамотно выполненный анализ требований -Правильность определения функциональной структуры ПО -Правильность определения состава компонент ПО
ПК 2. Выполнять интеграцию модулей в программную систему.	-  Проектирование многомодульных программ -  Выполнение интеграции программ в программную систему
ПК 3. Выполнять отладку программного продукта с использованием специализированных программных средств.	- Умение выполнять различные виды отладки - Умение находить и распознавать ошибки с помощью отладки
ПК 4. Осуществлять разработку тестовых наборов и тестовых сценариев.	-  Умение разрабатывать тестовые наборы и сценарии тестирования -  Умение выполнять тестирование с помощью различных методик -  Умение выполнять тестирование с помощью специализированных средств
ПК 5. Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.	-  Выполнение оценки качества программных компонент -  Умение выполнять оптимизацию программного кода
ПК 6. Разрабатывать технологическую документацию.	-  Грамотное составление технической и проектной документации -  Знание стандартов в области документирования и умение их использовать

 

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

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

 

 

Образовательный маршрут по

МДК 03.02 Инструментальные средства разработки программного обеспечения

Таблица 1

Формы отчетности, обязательные для сдачи	Количество
практические занятия	40
Точки рубежного контроля	3
Итоговая аттестация (при наличии)	экзамен

 

 

Желаем Вам удачи!

 

СОДЕРЖАНИЕ ДИСЦИПЛИНЫ

Раздел III.  Проектирование программного обеспечения с использованием специализированных программных пакетов

Тема 3.1 Проектирование процесса разработки программного продукта

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

План изучения темы: (перечень вопросов, обязательных к изучению):

1. Понятие и принципы работы с инструментальными средствами разработки ПО
2. Методы организации коллективной разработки ПО.
3. Основы календарного планирования работы.
4. Понятие ресурсов.

Краткое изложение теоретических вопросов:

Понятие и принципы работы с инструментальными средствами разработки ПО

В настоящее время компьютерную технологию разработки ПС можно характеризовать [16.1] использованием

·                     программной поддержки для разработки графических требований и графических спецификаций ПС,

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

·                     программной поддержки прототипирования.

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

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

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

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

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

 

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

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

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

Генерация программ ПС. На этом этапе автоматически генерирует скелеты кодов программ ПС или полностью коды этих программ по формальным спецификациям ПС.

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

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

Аттестация ПС имеет прежнее содержание.

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

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

·                     конструкторы пользовательских интерфейсов;

·                     инструмент работы со словарем именованных сущностей;

·                     графические и тестовые редакторы спецификаций;

·                     анализаторы спецификаций;

·                     генератор программ;

·                     документаторы.

 

Методы организации коллективной разработки ПО.

 

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

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

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

Во время разработки любого проекта необходимым действием является регулярное сохранение предыдущих версий файлов (backup) с возможностью быстрого их восстановления. Необходимость в этом возникает, в частности, при поиске причины появления новых ошибок между версиями (bug tracking). Самым простым решением является использование для этих целей мощного архиватора, стримера и т.п., но их работа при больших размерах проекта может растянуться на часы. Более того, часто желательно сохранять каждую версию каждого файла, снабжая ее для избежания путаницы комментарием: кто изменил этот файл и зачем. Для этих целей используются системы контроля версий (Version Control Systems).

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

Следовательно, наиболее приемлемым вариантом для разработчика является ПО, умеющее как объединять различные версии текста программы, так и вести полную историю изменений сразу нескольких проектов с совместным использованием общих компонентов в разных проектах (sharing) и ветвлением.

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

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

b)      все происходит, как в случае a), только объединение разработок дозволено нескольким людям;

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

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

Данная статья обсуждает в основном средства автоматизации объединения и контроля версий для случаев c) и d), характерных для достаточно больших и долгосрочных проектов. Также рассматривается возможность использования этих средств для случаев a) и b), обычных при разработке ПО более мелких масштабов, а также для ситуаций, когда передача информации затруднена (например, люди в основном работают дома и приносят на работу результаты своего труда на дискетах).

 

Основы календарного планирования работы.

 

Календарное планирование – это разработка и доведение до структурных подразделений и рабочих мест оперативных плановых заданий по выпуску продукции и обеспечению их необходимыми для этого ресурсами [1,c.603]. Календарный план производства – это документ, который устанавливает последовательность и сроки выполнения производственных операций, а также определяет потребность в трудовых ресурсах во времени. Объемно-календарный план или, как он именуется в зарубежной практике MPS (Master Production Schedule) имеет следующие значения: 1. Предполагаемый план производства изделий. Это строго производственный план компании (в отличие от прогноза и потребности), выраженный в определенном для производства ассортименте изделий, объемах и сроках их производства. При составлении объемно-календарных планов следует принимать во внимание прогноз, укрупненный производственный план, маркетинговые планы и планы замены продуктовых линий и другие исходные данные, такие как незавершенное производство готовой продукции, наличие материалов, производственных мощностей. 2. Результат процесса объемно-календарного планирования. План, регулирующий производство и закупку изделий, обусловленных данным методом планирования. 3. План более высокого порядка, чем производственный. Планирование осуществляется, как правило, в интервале от месяца до пяти лет. Может быть подготовлен как фактический, так и сценарный MPS. Р. Фатхутдинов выделяет следующие цели и задачи оперативно-календарного планирования (ОКП): Рис. 1. Цели и задачи календарного планирования. Календарный график – это графическая интерпретация календарного плана, конкретизирующая его относительно состава, объемов, последовательности, сроков выполнения работ. При построении календарного графика необходимо учитывать наличие ресурсов, так как одновременное выполнение некоторых операций из-за ограничений, связанных с рабочей силой, оборудованием и другими видами ресурсов, может оказаться невозможным На производстве календарный план часто называют планом-графиком. Выделяют четыре вида календарных графиков в зависимости от решаемых задач:

1. Сводный календарный план или график. В нем указываются уточнённые сроки выполнения работ всем предприятием.

2. Объёмный календарный график. Он определяет очерёдность и сроки выполнения каждого вида работ в конкретном подразделении предприятия.

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

4. Часовые календарные графики. Используются в технологических картах и картах трудовых процессов, для формирования оптимальной загрузки ОПФ и трудовых ресурсов на предприятии. Данные графики оптимизированы или ориентированы на типичные или наиболее вероятные условия работы и в конкретных условиях требуют уточнения. При формировании годового календарного плана выпуска продукции необходимо, чтобы календарное распределение обеспечивало:  Установленные сроки выпуска и поставки готовых изделий, обусловленные договорами;  Возможность внесения корректив в связи с колебанием спроса;  Минимальное незавершённое производство путем уплотнения производственного цикла изготовления изделий;  Максимально возможное использование производственных мощностей цехов в каждом месяце;  Создание предпосылок для слаженной и сопряжённой работы производственныхØ подразделений и условий для эффективного функционирования предприятия в целом. Процесс календарного планирования осуществляется обратно ходу технологического процесса, т.е. плановые решения начинают формироваться на стадии готовой продукции. При этом он зависит от организационного типа и условий производства, учитываются сроки окончания технической подготовки производства, обеспечивается параллельное изготовление тех видов продукции, которые, с одной стороны, имеют максимальную конструктивно-техническую общность, а с другой – дополняют друг друга по трудоёмкости, обеспечивая в совокупности достаточно полную загрузку оборудования и рабочей силы. Основные ресурсы учитываемы в формировании календарного плана:

 1. Трудовые ресурсы (руководители, сотрудники плановых служб).

2. Технические средства.

3. Экономико-математическое обеспечение

4. Информационное обеспечение.

5. Календарно-плановые нормативы.

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

 

Лабораторные работы/ Практические занятия:

-Создание календарного плана в MS Project

-Оптимизация ресурсов планирования в MS Project

-Выравнивание ресурсов в MS Project

-Отслеживание проекта

-Анализ выполнения плана в MS Project

Задания для самостоятельного выполнения:

-Подготовка реферата «Обзор инструментальных средств различных направлений»

-Подготовка сообщения «Распределение обязанностей при командной работе над проектом»

-Составление календарного плана работы над собственным проектом

-Подготовка сообщения «Методы оптимизации календарного планирования»

Форма контроля самостоятельной работы:

-Подготовка реферата

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

• Что представляют собой CASE-средства разработки ИС?
• Какие модели можно построить с помощью CASE-средств BPwin и ERwin?
• Перечислите требования, предъявляемые к методикам и программным инструментальным средствам разработки ИС.

·        Что позволяет коллективное владение кодом

·        Как повысить эффективность коллективной работы

·        Какие существуют психологические командные роли

·        В чем отличие авторской разработки от коллективной

·        Дайте определение понятию коллективной разработки Какие методы существуют календарного планирования

·        В чем их отличие

·        В чем заключаются задачи календарного планирования

 

 

Тема 3.2 Использование основных методологий процессов разработки ПО

Основные понятия и термины по теме: методология IDEF0, Методология DFD, процессы IDEF3, методология ARIS eEPC.

План изучения темы: (перечень вопросов, обязательных к изучению):

1. Принципы методологии IDEF0
2. Методология DFD.
3. Методология описания процессов IDEF3
4. Имитационное моделирование
5. Методологии моделирования данных.
6. Генерация кода клиентской части с помощью ERwin.
7. Основные понятия методологии ARIS.
8. Моделирование требований к ПО с помощью ARIS eEPC

Краткое изложение теоретических вопросов:

Принципы методологии IDEF0

Принципы построения модели IDEF0

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

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

Следует указать на распространенную ошибку при создании модели AS-IS - это создание

 

 

 

 

Методология DFD.

 

Целью методики является построение модели рассматриваемой системы в видедиаграммы потоков данных (Data Flow Diagram – DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов.

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

– потоки данных,

– процессы (работы) преобразования входных потоков данных в выходные,

– внешние сущности,

– накопители данных (хранилища).

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

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

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

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

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

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

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

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

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

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

– наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

– возможности описания преобразования данных процессов в виде последовательного алгоритма;

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

– возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

 

Методология описания процессов IDEF3

 

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

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

1. Документировать данные о технологии процесса.

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

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

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

5. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." Такая возможность существует при использовании, например, системы имитационного моделирования ARENA.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу, называются диаграммами потокового описания процесса(Process Flow Description Diagrams, PFDD), а ко второму – диаграммами сети изменения состояний объектов (Object State Transition Network, OSTN).

 

 

 

Таблица 3.4. Типы связей IDEF3

 

Изображение	Название	Назначение
	Временное предшествование (Temporal precedence)	Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия (исходное действие должно завершиться, прежде чем конечное действие сможет начаться)
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

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

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

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

Объект, обозначенный J1, называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и перекрестки для разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в табл.

 

Таблица 3.5. Типы перекрестков

 

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы должны быть завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следу­ющих процессов должны быть запущены
	Synchronous OR	Один или несколько предшествующих процессов завершаются одновременно	Один или несколько следу­ющих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий про­цесс запускается

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

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

 

Имитационное моделирование

 

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

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

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

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

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

 

Методологии моделирования данных.

 

Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения. Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС. Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:  время решения задач;  стоимостные затраты на обработку данных;  надежность процессов;  косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д. Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования. В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации. Объектная структура Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов. На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.). На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области. Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах. Функциональная структура Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа «Заказ», который, в свою очередь, порождает документ «Накладная», сопровождающий партию отгруженного товара. Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы, и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий. На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20. На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций. На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции. Структура управления В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый бизнес-процесс. Тогда последовательность событий составляет конкретную реализацию бизнес-процесса. Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций бизнес-процессов. На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.). На концептуальном уровне устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов. На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей. Организационная структура Организационная структура представляет собой совокупность организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов. В функционально-ориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций, входящих в один тип процесса и относящихся к разным функциям управления. На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений. На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала). На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы. Техническая структура Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений. На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям. На концептуальном уровне определяется способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д. На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети. Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: «объекты-функции», «функции-события», «организационные единицы — функции», «организационные единицы — объекты», «организационные единицы — технические средства» и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий. Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач. Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа. Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте. Функция – совокупность операций, сгруппированных по определенному признаку. Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя. Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя. Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия. Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии. Функционально-ориентированные и объектно-ориентированные методологии описания предметной области Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные). Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации.

 

Генерация кода клиентской части с помощью ERwin.

 

ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Расчет строится на основе следующих параметров: начальное количество строк; максимальное количество строк; прирост количества строк в месяц. Результаты расчетов сводятся в отчет.

ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения (в том числе и визуальных), которые будут отображать информацию, хранящуюся в соответствующей колонке. Эта информация записывается в файле модели. На основе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код может быть откомпилирован и выполнен без дополнительного ручного кодирования.

Каждой колонке в модели ERwin можно задать предварительно описанные и именованные свойства:

§     правила валидации (проверка значений);

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

§     стиль визуального объекта (например, радиокнопка, поле ввода и др.);

§     формат изображения.

Для описания каждого свойства ERwin содержит соответствующие редакторы.

 

Основные понятия методологии ARIS.

 

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

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

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

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

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

В семейство ARIS входят следующие модули:

·                     ARIS Toolset - базовая инструментальная среда;

·                     ARIS Easy Design - упрощенная среда моделирования;

·                     ARIS Simulation - модуль динамического имитационного моделирования;

·                     ARIS Link for R/3 - модуль, обеспечивающий интеграцию с репозиторием R/3;

·                     ARIS Analyzer for R/3 - модуль проверки создаваемых моделей на соответствие методологии SAP;

·                     ARIS Promt - модуль стоимостного анализа;

·                     дополнительные модули-интерфейсы, обеспечивающие интеграцию с системами Microsoft Project, ER/win, Designer/2000, IBM Flowmark (класс workflow), Staffware и т.д.

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

Методология моделирования ARIS

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

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

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

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

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

 

Моделирование требований к ПО с помощью ARIS eEPC

 

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

Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций и т.п., а детальное описание процессов само по себе не представляет ценности.Реинжиниринг бизнес-процессов (англ. Business process reengineering) - это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимальной эффективности производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели "как есть", её анализ, разработка модели "как надо") и разработки и реализации плана перехода к состоянию "как надо".

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam - это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

· Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов - стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.

· Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

· Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

Важным элементом модели бизнес-процессов являются бизнес-правила или правила предметной области. Типичными бизнес-правилами являются корпоративная политика и государственные законы. Бизнес-правила обычно формулируются в специальном документе и могут отражаться в моделях.
Декомпозиция в общем смысле - это метод, позволяющий заменить решение одной большой задачи решением серии меньших задач, расщепление объекта на составные части по установленному критерию. Практически декомпозиция применяется для детализации бизнес-моделей.
Этапы описания бизнес-процессов:
" Определение целей описания.
" Описание окружения, определение входов и выходов бизнес-процесса, построение IDEF0-диаграмм.
" Описание функциональной структуры (действия процесса), построение IDEF3-диаграмм.
" Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.
" Построение организационной структуры процесса (отделы, участники, ответственные).

IDEF0

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

· Управляющая информация входит в блок сверху.

· Входная информация входит в блок слева.

· Результаты выходят из блока справа.

· Механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу.

Лабораторные работы/ Практические занятия:

-Анализ документации на создание программной системы с помощью IDEF0

-Проектирование внешнего окружения системы с помощью IDEF0

-Проектирование процессов программной системы с помощью IDEF0

-Оптимизация организационной структуры с помощью IDEF0

-Моделирование системы интеграции модулей с помощью DFD

-Моделирование потоков данных с помощью DFD

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

-Проектирование процессов программной системы с помощью IDEF3

-Моделирование данных с помощью ERD

-Моделирование требований к ПО с помощью ARIS eEPC

-Моделирование структуры ПО с помощью ARIS eEPC

 

Задания для самостоятельного выполнения:

-Изучение методик проектирования по учебнику

-Применение методологии IDEF0 для собственного проекта

-Применение методологии DFD для собственного проекта

-Обзор инструментальных средств имитационного моделирования с помощью ресурсов Интернет

-Применение методологии ERD для собственного проекта

-Сравнительный обзор методологий проектирования ПО

-Применение методологии ARIS для собственного проекта

Форма контроля самостоятельной работы:

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

1. Как применяется методология IDEF0
2. Как применяется методология DFD
3. Как применяется методология ERD
4. Как применяется методология ARIS
5. Как происходит процесс моделирование потоков данных

 

Тема 3.3 Инструментальные средства отладки и тестирования

Основные понятия и термины по теме: Отладка, Ruby\Watir

План изучения темы: (перечень вопросов, обязательных к изучению):

1. Инструментальные средства отладки.
2. Виды отладки.
3. Средства повышения эффективности.
4. Автоматизация тестирования ПО. 
5. Техники тестирования. 
6. Основные инструменты автоматизированного тестирования.
7. Тестирование ПО с помощью Ruby\Watir.

Краткое изложение теоретических вопросов:

Инструментальные средства отладки.

Инструментальные средства поддержки технологии проектирования и аудита информационных систем и сервисов

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

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

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

·                     гарантия создания системы с заданными параметрами в течение заданного вре­мени в рамках оговоренного заранее бюджета;

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

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

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

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

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

Технология проектирования может быть представлена как совокупность трех со­ставляющих:

·                     заданной последовательности выполнения технологических операций проек­тирования;

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

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

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

·                     данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

·                     методическими материалами, инструкциями, нормативами и стандартами;

·                     программными и техническими средствами;

·                     исполнителями.

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

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

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

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

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

·                     технология должна обеспечивать возможность ведения работ по проектирова­нию отдельных подсистем небольшими группами (3-7 человек). Это обуслов­лено принципами управляемости коллектива и повышения производительно­сти за счет минимизации числа внешних связей;

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

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

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

CASE-технологии

CASE(Computer-AidedSoftware/SystemEngineering) как новое направление в программировании сформировалось за последние 10-15 лет.

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

 

Виды отладки.

 

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

Отладка = Тестирование + Поиск ошибок + Редактирование.

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

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

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

Рис. 10.1. Спектр подходов к проектированию тестов.

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

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

 

Средства повышения эффективности.

 

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

Основные направления повышения эффективности использования ОПФ:

1) рост уровня фондообеспеченности предприятия

2) совершенствование средств труда, повышение их надежности и долговечности

3) улучшение технического обслуживания

4) оптимизация структуры ОФ

5) установление оптимальной пропорции между ОПФ и оборотными средствами

6) внедрение прогрессивных технологий

7) повышение квалификации кадров, их стимулирование.

 

Автоматизация тестирования ПО.

 

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

а) предполагаемые результаты должны быть известны до тестирования;

б) следует избегать тестирования программы автором;

в) необходимо досконально изучать результаты каждого теста;

г) необходимо проверять действия программы на неверных данных;

д) необходимо проверять программу на неожиданные побочные эффекты на неверных данных.

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

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

Ручной контроль используют на ранних эта­пах разработки. Все проектные решения анализируются с точки зрения их правильности и целесообразности как можно раньше, пока их можно легко пересмотреть. Различают статический идинамический подходы к ручному контролю. При статическомподходе анализируют структуру, управляющие и инфор­мационные связи программы, ее входные и выходные данные. При динамическом - выполняют ручное тестирование (вручную моделируют про­цесс выполнения программы на заданных исходных данных). Исходными данными для таких проверок являются: техническое зада­ние, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов, а для более поздних этапов - алгоритмы и тексты программ, а также тестовые наборы. Доказано, что ручной контроль способствует существенному увеличе­нию производительности и повышению надежности программ и с его помо­щью можно находить от 30 до 70 % ошибок логического проектирования и кодирования. Основными методами ручного контроля являются: инспекции исходного текста, сквозные просмотры, проверка за столом, оценки программ.

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

 

Тестирование ПО с помощью Ruby\Watir.

 

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

·                     модульное тестирование;

·                     интеграционное тестирование;

·                     системное тестирование;

·                     приемочное тестирование.

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

В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.

Библиотека Watir

Для управления браузером библиотека Watir использует протокол OLE. Это накладывает определенные ограничения как на выбор платформы, так и на выбор браузера. Так, на момент написания этих строк Watir работает только под Windows и только с Internet Explorer. Не отчаивайтесь раньше времени если у вас другая система или вы пользуетесь другим браузером! Существуют версии Watir для Firefox и для Safari:

·                     FireWatir - работает с Firefox под Linux, Windows и Mac;

·                     SafariWatir - работает с Safari под Mac.

В перспективе разработчики планируют объединить все три версии в один проект. Отмечу, что аналоги Watir есть и для других языков программирования:

·                     Watij - версия Watir для Java;

·                     WatiN - версия Watir для .Net;

·                     BrowserUnit - еще одна версия Watir для .Net.

Лабораторные работы/ Практические занятия:

-Отладка программ с помощью встроенного отладчика Delphi

-Повышение эффективности программного кода с помощью инструментов среды Delphi

-Тестирование программы  с помощью Ruby\Watir

Задания для самостоятельного выполнения:

-Аналитический обзор средств отладки. Работа с ресурсами Интернет

-Подготовка реферата «Основные методы отладки»

-Подготовка сообщения «Средства повышения эффективности программ»

-Обзор средств автоматизированного тестирования по материалам сети Интернет.

-Отладка программ для собственного проекта

Форма контроля самостоятельной работы:

-Подготовка реферата

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

1.      Для чего необходимо тестирование проекта

2.      Что необходимо для отладки программ

3.      Какие средства повышения эффективности разработки ПО

 

 

 

 

 

 

 

 

 

 

 

 

 

КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ  ОСВОЕНИЯ ДИСЦИПЛИНЫ

 

Текущий контроль

 

Перечень точек рубежного контроля	Охват тем (указать номера тем, подлежащих контролю)	Форма контроля
1	3.1	Тестовые задания
2	3.2.	Тестовые задания
3	3.3.	Контрольная работа

 

Итоговый контроль по дисциплине

 

     3.3.1. Теоретические вопросы

1.      Дайте определение понятия проект. Охарактеризуйте состав и структуру коллектива разработчиков, их функции.

2.      Охарактеризуйте структурный подход к проектированию ИС. CASE - средства разработки ПО.

3.      . Опишите как осуществляется моделирование потоков данных (процессов). Внешние сущности. Системы и подсистемы. Процессы. Накопители данных. Потоки данных. Построение иерархии диаграмм потоков данных.

4.      Охарактеризуйте метод моделирования IDEF3.

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

6.      Опишите инструменты функционального моделирования бизнес-процессов и использованием стандарта IDEF0.

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

8.      Опишите методы организации коллективной разработки ПО

9.      Охарактеризуйте процесс разработки сетевой модели

10.  Опишите элементы Microsoft Office Project 2007

11.  Опишите элементы графической нотации DFD

12.  Опишите элементы методологии IDEF0

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

14.   Опишите Case-метод Баркера

15.  Объясните как осуществляется генерация кода клиентской части с помощью ERwin

16.  Опишите нотацию ARIS eEPC

17.  Охарактеризуйте модель AS-IS

18.   Охарактеризуйте модель ТО-ВЕ

19.  Дайте определение понятию отладки программного средства

20.  Дайте определение понятию программного модуля.

21.  Опишите методические аспекты проектирования ПО. Общие принципы проектирования систем.

22.  Расскажите про основы объектно-ориентированного подхода к анализу и проектированию ПО. Унифицированный язык моделирования UML.

23.  Объясните функциональное проектирование ИСО, IDEF0, синтаксис, особенности проектирования.

24.  . Объясните функциональное проектирование ИСО, IDEF3, синтаксис, особенности проектирования.

25.   Опишите методологию DFD для проектирования ИСО.

 

3.4.  Перечень практических заданий

Задание 1.

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

№	Название задачи	Длит (дн)	Предшественники
1	Начало проекта	0
2	Утверждение проектов
3	Начало утверждения проектов	0	1
4	Утверждение проекта на строительство	90	3
5	Утверждение проекта на газ	60	3
6	Утверждение проекта на водопровод и канализацию	30	3
7	Утверждение проекта на отопление	45	3
8	Проекты утверждены	0	4; 5; 6; 7
9	Строительство фундамента
10	Начало закладки фундамента	0	8
11	Рытье траншей	10	10
12	Заливка фундамента	5	11
13	Фундамент завершен	0	12
14	Каркас и крыша
15	Начало каркаса	0	13
16	Кладка стен	60	15
17	Перекрытие стен	15	16
18	Установка крыши	30	17
19	Установка наружных дверей и окон	7	17
20	Установка полов	5	17
21	Каркас готов	0	18; 19; 20
22	Коммуникации
23	Начало установки коммуникаций	0	21
24	Проведение и подключение водопровода и канализации	10	23
25	Установка и подключение электропроводки	5	23
26	Установка и подключение газовых коммуникаций	5	23
27	Коммуникации готовы	0	24; 25; 26
28	Внутренняя отделка
29	Начало отделки	0	27
30	Внутренние двери	10	29
31	Навесные потолки	5	30
32	Отделка стен	3	30
33	Монтаж отопления	10	30
34	Установка оборудования, приборов и сантехники	5	31; 33
35	Настил полов	15	32; 34
36	Конец отделки	0	35
37	Конец проекта	0	36

2.    Между работами 12 и 13 установить задержку в 30 дней, необходимую для выдержки фундамента.

3.    Для задачи 32 установить ограничение Как можно позже.

Задание2

·       Создать проект Внедрение бухгалтерской системы, предназначенный для автоматизации бухгалтерии небольшого предприятия, состоящей из 10 человек. Дата начала проекта – 1 июля 2010 года. Перечень задач проекта, их связи и длительности приведены в таблице. Фазы выделены полужирным курсивом, а вехи имеют нулевую длину. Названия задач, входящих в фазу, выделены отступом слева.

№	Название задачи	Длит (дн)	Предшественники
1	Начало проекта	0
2	Выбор системы
3	Изучение рынка бухгалтерских систем	7	1
4	Составление требований к бухгалтерским системам	7	1
5	Консультации с фирмами-разработчиками	7	3;4
6	Принятие окончательного решения	2	5
7	Выбор завершен	0	6
8	Приобретение программного обеспечения
9	Заключение договоров	6	2
10	Оплата за ПО	2	9
11	Оформление ПО на баланс	3	10
12	Приобретение ПО завершено	0	11
13	Составление проекта сети
14	Разработка архитектуры сети	7	7
15	Проработка физического размещения сети	5	14
16	Проект сети завершен	0	15
17	Приобретение компьютеров и сетевого оборудования
18	Сбор информации о поставщиках и предложениях	7	7
19	Анализ и выбор поставщика	5	14;18
20	Заключение договоров	5	19
21	Оплата за оборудование	2	20
22	Оформление оборудования на баланс	3	21
23	Приобретение оборудования завершено	0	22
24	Обучение администратора и программиста
25	Курсы администраторов	18	16
26	Курсы программистов	18	12
27	Сдача сертификационных экзаменов	3	25;26
28	Обучение завершено	0	27
29	Монтаж локальной сети
30	Установка компьютеров на рабочих местах	3	23;28
31	Монтаж кабеля	10	23;28
32	Монтаж сетевых устройств	10	23;28
33	Подключение кабеля к компьютерам и сетевым устройствам	5	30;31;32
34	Монтаж завершен	0	33
35	Установка ПО на компьютеры
36	Установка сервера	5	34
37	Создание доменов и пользователей	7	36
38	Проверка и настройка работы сети	5	37
39	Настройка сети завершена	0	38
40	Ввод начальных данных
41	Ввод справочников	40	39
42	Ввод начальных остатков	40	41
43	Ввод начальных данных завершен	0	42
44	Обучение персонала
45	Принципы работы системы	3	39
46	Изучение интерфейса	5	45
47	Изучение справочников	20	41;46
48	Изучение документов и журналов	30	42;47
49	Обучение завершено	0	48
50	Передача в эксплуатацию
51	Формирование тестовой отчетности	5	49
52	Акт ввода в эксплуатацию	3	51
53	Передача в эксплуатацию завершена	0	52
54	Конец проекта	0	53

·       Между задачами 10 и 11 установить задержку в 5 дней, необходимую для прохождения безналичной оплаты.

·       Между задачами 21 и 22 установить задержку в 7 дней, необходимую для прохождения безналичной оплаты и доставки оборудования.

·       Установить тип связи между задачами 41 и 47 начало-начало и задержку в 5 дней.

·       Установить ограничение для задачи 42 ограничение не ранее 1.01.2011.

Задание 3

·       Создать проект Ремонт квартиры, предназначенный для проведения ремонта в двухкомнатной квартире. Дата начала проекта – 1 февраля 2010 года. Перечень задач проекта, их связи и длительности приведены в таблице. Фазы выделены полужирным курсивом, а вехи имеют нулевую длину. Названия задач, входящих в фазу, выделены отступом слева.

№	Название задачи	Длит (дн)	Предшественники
1	Начало проекта	0
2	Замена окон
3	Замер окон	2	1
4	Заказ и оплата окон	2	3
5	Установка окон	2	4
6	Отделка откосов	2	5
7	Замена окон завершена	0	6
8	Замена дверей
9	Замер дверей	2	1
10	Заказ и оплата дверей	2	9
11	Установка дверей	3	10
12	Замена дверей завершена	0	11
13	Замена отопительных приборов
14	Заказ и оплата отопительных приборов	3	1
15	Установка отопительных приборов	5	14
16	Замена отопительных приборов завершена	0	15
17	Выравнивание стен
18	Стены в спальне	4	7;12;16
19	Стены в гостиной	4	18
20	Стены в кухне	3	19
21	Стены в прихожей	4	20
22	Выравнивание стен завершено	0	21
23	Санузел
24	Снятие штукатурки в санузле	3	12;16
25	Отделка стен санузла	4	24
26	Отделка потолка санузла	2	25
27	Отделка пола санузла	2	25
28	Установка сантехнического оборудования	1	27
29	Ремонт санузла завершен	0	28
30	Ванная
31	Снятие штукатурки в ванной	3	12;16
32	Отделка стен ванной	5	31
33	Отделка потолка ванной	2	32
34	Отделка пола ванной	2	33
35	Установка сантехники	1	34
36	Ремонт ванной завершен	0	35
37	Отделка стен
38	Отделка стен в спальне	5	22;29;36
39	Отделка стен в гостиной	7	38
40	Отделка стен в кухне	5	39
41	Отделка стен в прихожей		40
42	Отделка стен завершена	0	41
43	Потолки
44	Замер	2	22
45	Заказ и оплата потолков	2	44
46	Навесной потолок в спальне	2	38;45
47	Навесной потолок в гостиной	2	39;45
48	Панельный потолок в кухне	2	40
49	Навесной потолок в прихожей	2	41;45
50	Монтаж потолков завершен	0	46;4;48;49
51	Полы
52	Отделка полов в спальне	6	46
53	Отделка полов в гостиной	6	47
54	Отделка полов на кухне	3	48
55	Отделка полов в прихожей	5	49
56	Отделка полов завершена	0	52;53;54;55
57	Оборудование кухни
58	Заказ и оплата кухонного оборудования	5	48
59	Замена кухонного оборудования	3	54;58
60	Оборудование кухни завершено	0	59
61	Конец проекта	0	60

Установить задержки между задачами в соответствии с таблицей

Предшественник	Последователь	Задержка
4	5	15
5	6	15
10	11	7
14	15	5
45	46	20
45	47	20
45	49	20
58	59	25

 

 

Задание 4

1.    В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН- Строительство дома создать список ресурсов в соответствии с параметрами, перечисленными в таблице

		Таблица норм	Станд.ставка	Ставка сверхур.	Затраты на исп.
Архитектор	Т	А	-		55000
МУП "Горгаз"	T	A	-		70000
МУП "Водоканал"	T	A	-		50000
АО "Водолей"	T	A	-		50000
Рабочий1	T	A	1000р/д		-
Рабочий2	T	A	1000р/д		-
Рабочий3	T	A	1000р/д		-
Подсобник1	T	A	400 р/д		-
Подсобник2	T	A	400 р/д		-
Трактор	T	A			7000
Плотник1	T	A B	1500 р/д –	200р./ч	– 7500
Плотник2	T	A B	1500 р/д –	200р./ч	– 7500
"Неопласт"	T	A	-		120000
Водопроводчик1	T	A	800 р/д		-
Водопроводчик2	T	A	800 р/д		-
Электрик	T	A	1000 р/д		-
АО "Газовик"	T	A	-		25000
ООО "Потолки"	T	A	-		150000
Песок	M	A	500 р/т		-
Щебень	M	A	600 р/т		-
Цемент	M	A	-
Кирпич	M	A	7 р/шт		-
Брус	M	A	-		25000
Доска обрезная	M	A	7000р/м3		-
Доска необрезная	M	A	5000р/м3		-
Шифер	M	A	-		40000
Электропровод	M	A	-		15000
Электросчетчик	M	A	-		5000
Труба водопроводная	M	A	-		35000
Труба канализационная	M	A	-		30000
Штукатурка	M	A	-		150000
Потолок	M	A	150 р/м2		-
Окно	M	A	10000		-
Дверь наружная	M	A	-		20000
Труба отопительная	M	A	-		20000
Котел	M	A	-		40000
Печь газовая	M	A	-		20000
Ванна	M	A	45000		-
Унитаз компакт	M	A	20000		-
Раковина	M	A	16000		-
Кран	M	A	7000		-
Паркет	M	A	550 р/м2		-
Труба газовая	M	A	-		50000
Дверь внутренняя	M	A	9000		-
Доставка	З

2.    Создать назначения ресурсов в соответствии с таблицей

Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
Утверждение проекта на строительство	Архитектор	100	A
Утверждение проекта на газ	МУП "Горгаз"	100	A
Утверждение проекта на водопровод и канализацию	МУП "Водоканал"	100	A
Утверждение проекта на отопление	АО "Водолей"	100	A
Рытье траншей	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Трактор	100 100 100 100 100 100	А А А А А А
Заливка фундамента	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Песок Щебень Цемент Доска необрезная Доставка	100 100 100 100 100 10т 10т 2500кг 3м3 25000р	А А А А А А А А А
Кладка стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Кирпич Песок Цемент Доставка	100 100 100 100 100 70000 6т 2000кг 25000р	А А А А А А А А
Перекрытие стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Брус Доска обрезная Доставка	100 100 100 100 100 1 7 м3 15000р	А А А А А А А
Установка крыши	Плотник1 Плотник2 Доска необрезная Шифер Доставка	100 100 10 1 12000р	А А А А
Установка наружных дверей и окон	ООО "Неопласт" Окно Дверь неружная	100 9 1	А А А
Установка полов	Плотник1 Плотник2 Доска обрезная Доставка	100 100 10 7000р	А А А
Проведение и подключение водопровода и канализации	Водопроводчик1 Водопроводчик2 Труба водопров Труба канализ	100 100 1 1	А А А А
Установка и подключение электропроводки	Электрик Электросчетчик Электропровод	100 1 1	А А А
Установка и подключение газовых коммуникаций	АО "Газовик" Труба газовая	100 1	А А
Отделка стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Штукатурка	100 100 100 100 100 1	А А А А А А
Навесные потолки	ООО "Потолки" Потолок	100 190	А А
Внутренние двери	Плотник1 Плотник2 Дверь внутренняя Доставка	100 100 10 10000р	В В А
Монтаж отопления	Водопроводчик1 Водопроводчик2 Труба отопит.	100 100 1	А А А
Установка оборудования, приборов и сантехники	Водопроводчик1 Водопроводчик2 Котел Печь газовая Ванна Унитаз компакт Раковина Кран	100 100 1 1 1 2 3 4	А А А А А А А А
Настил полов	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Паркет	100 100 100 100 100 190	А А А А А А

3.    Установить профили загрузки ресурсов: МУП "Горгаз" – затраты в конце, МУП "Водоканал" – поздний пик, АО "Водолей" – колокол.

 

 

Задание 5

1.    В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН- Внедрение бухгалтерской системы создать список ресурсов в соответствии с параметрами, перечисленными в таблице

		Таблица норм	Станд. ставка	Ставка сверхур.	Затраты на исп
Главбух	T	A B	90000р./мес	500р./ч	30000р
Администратор	Т	А В	70000р./мес	450р./ч	40000р
Программист	T	A B	60000р./мес	400р./ч	50000р
Техник	T	A	40000р./мес	250р./ч	-
Расчетчик1	T	A	40000р./мес	250р./ч	-
Расчетчик2	T	A	40000р./мес	250р./ч	-
Расчетчик3	T	A	40000р./мес	250р./ч	-
Бухгалтер мат. учета1	T	A	40000р./мес	250р./ч	-
Бухгалтер мат. учета2	T	A	40000р./мес	250р./ч	-
Бухгалтер учета ОС и НМА	T	A	40000р./мес	250р./ч	-
Бухгалтер учета ОС	T	A	40000р./мес	250р./ч	-
Бухгалтер учета реализации	T	A	40000р./мес	250р./ч	-
Бухгалтер производ-ственного учета	T	A	40000р./мес	250р./ч	-
Компьютер	M	A	15000		-
Сервер	M	A	50000		-
Принтер	M	A	5000		-
МФУ	M	A	7000		-
Сетевой кабель	M	A	-		15000
Сетевой концентратор	M	A	3000		-
Панель	M	A			10000
Разъемы и розетки	M	A	-		15000
Бухгалтерская система	M	A	-		100000
Офисный пакет	M	A	-		70000
ОС рабочей станции	M	A	-		60000
Серверная ОС	M	A	-		30000
DVD-матрица	M	A	10		-
Интернет	З
Междугородние переговоры	З
Оплата курсов	З

2.    Создать назначения ресурсов в соответствии с таблицей

Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
Изучение рынка бухгалтерских систем	Администратор Интернет	100	A 1500
Составление требований к бухгалтерским системам	Администратор Главбух	100 20	A A
Консультации с фирмами-разработчиками	Администратор Междугородние переговоры Интернет	100	A 2000 1000
Принятие окончательного решения	Администратор Главбух	100 100	A A
Заключение договоров	Администратор Программист Главбух	100 100 100	A A A
Оплата за ПО	Главбух Бухгалтерская система Офисный пакет ОС рабочей станции Серверная ОС	10	A A A A A
Оформление ПО на баланс	Бухгалтер учета ОС и НМА	30	A
Разработка архитектуры сети	Администратор Программист Техник	100 100 50	A A A
Проработка физического размещения сети	Администратор Программист Техник	100 100 100	A A A
Сбор информации о поставщиках и предложениях	Администратор Интернет Междугородние переговоры	50	A 1000 1500
Анализ и выбор поставщика	Администратор Главбух Интернет	50 20	A A 1000
Заключение договоров	Администратор Главбух	100 50	A A
Оплата за оборудование	Главбух Компьютер Сервер Принтер МФУ Сетевой кабель Сетевой концентратор Панель Разъемы и розетки	30 12 1 2 2 2	А А А А А А А А А
Оформление оборудования на баланс	Бухгалтер учета ОС	70	A
Курсы администраторов	Администратор Оплата курсов	100	A 25000
Курсы программистов	Программист Оплата курсов	100	A 2000
Сдача сертификационных экзаменов	Администратор Программист	100 100	A A
Установка компьютеров на рабочих местах	Техник	100	A
Монтаж кабеля	Техник	100	A
Монтаж сетевых устройств	Техник	100	A
Подключение кабеля к компьютерам и сетевым устройствам	Техник	100	A
Установка сервера	Администратор	100	A
Создание доменов и пользователей	Администратор	100	A
Проверка и настройка работы сети	Администратор Программист	100 100	A A
Ввод справочников	Администратор Программист Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета DVD-матрица	100 100 30 30 30 50 50 50 50 50 50 10	В В А А А А А А А А А А
Ввод начальных остатков	Администратор Программист Главбух DVD-матрица	100 100 50 10	В В А А
Принципы работы системы	Администратор Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение интерфейса	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение справочников	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение документов и журналов	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Формирование тестовой отчетности	Администратор Программист Главбух	100 100 100	А А А
Акт ввода в эксплуатацию	Администратор Главбух	50 50	А А

·      Установить различные профили загрузки для ресурса Техник.

 

 

 

Задание 6

·      В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН - Ремонт квартиры создать список ресурсов в соответствии с параметрами, перечисленными в таблице

		Таблица норм	Станд.ставка	Ставка сверхур.	Затраты на исп.
"Неопласт"	T	A B			12000p
"Крепкие двери"	T	A B	2000р./д
"Горгаз"	T	A			25000р
Слесарь-водопроводчик	T	A B	/1000р./д	150р./ч	20000р
Штукатур	T	A	800р./д	100р./ч	-
Подсобник	T	A	400р./д	50р./ч	-
Плиточник	T	A	1500р./д	200р./ч	-
Плотник	T	A	1500р./д	200р./ч	-
"Светлый потолок"	T	A	1000р./д	150р./ч	-
Окно	M	A	10000		-
Дверь	M	A	9000		-
Двухконтурный котел	M	A	55000		-
Отопительная батарея	M	A	5000		-
Унитаз-компакт	M	A	15000		-
Ванна	M	A	35000		-
Раковина	M	A	25000		-
Смеситель с душем	M	A	10000		-
Плитка	M	A	1000р./кв.м		-
Панель	M	A	500р./шт		-
Обои	M	A	1500р./рулон		-
Навесной потолок	M	A	-		70000
Паркет	M	A	1500р./кв.м		-
Газовая печь	M	A	-		25000
Вытяжка	M	A	-		15000
Мойка	M	A	-		10000
Смеситель	M	A	-		12000
Доставка	З

·      Создать назначения ресурсов в соответствии с таблицей

Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
Замер окон	"Неопласт"	100	A
Заказ и оплата окон	Окно	3	A
Установка окон	"Неопласт"	100	A
Отделка откосов	"Неопласт"	100	B
Замер дверей	"Крепкие двери"	100	A
Заказ и оплата дверей	Дверь	6	A
Установка дверей	"Крепкие двери"	100	B
Заказ и оплата отопительных приборов	Двухконтурный котел Отопительная батарея	1 3	A A
Установка отопительных приборов	Слесарь-водопроводчик Подсобник	100 100	A A
Стены в спальне	Штукатур	100	A
Стены в гостиной	Штукатур	100	A
Стены в кухне	Штукатур	100	A
Стены в прихожей	Штукатур	100	A
Снятие штукатурки в санузле	Подсобник	100	A
Отделка стен санузла	Плиточник Плитка	100 10	A A
Отделка потолка санузла	Плиточник Панель	100 5	A A
Отделка пола санузла	Плиточник Плитка	100 5	A A
Установка сантехнического оборудования	Слесарь-водопроводчик Унитаз-компакт	100 1	B A
Снятие штукатурки в ванной	Подсобник	100	A
Отделка стен ванной	Плиточник Плитка	100 10	A A
Отделка потолка ванной	Плиточник Панель	100 6	A A
Отделка пола ванной	Плиточник Плитка	100 6	A A
Установка сантехники	Слесарь-водопроводчик Ванна Раковина Смеситель с душем	100 1 1 1	B A A A
Отделка стен в спальне	Штукатур Обои	100 8	A A
Отделка стен в гостиной	Штукатур Обои	100 8	A A
Отделка стен в кухне	Штукатур Плиточник Плитка Панель	100 100 5 10	A A A A
Отделка стен в прихожей	Штукатур Плиточник Панель	100 100 15	A A A
Замер	"Светлый потолок"	100	A
Заказ и оплата потолков	Навесной потолок	1	A
Навесной потолок в спальне	"Светлый потолок"	100	A
Навесной потолок в гостиной	"Светлый потолок"	100	A
Панельный потолок в кухне	Плиточник Панель	100 6	A A
Навесной потолок в прихожей	"Светлый потолок"	100	A
Заказ и оплата кухонного оборудования	Газовая печь Вытяжка Мойка Смеситель	1 1 1 1	A A A A
Замена кухонного оборудования	Слесарь-водопроводчик	100	B
Отделка полов в спальне	Плотник Паркет	100 20	A A
Отделка полов в гостиной	Плотник Паркет	100 20	A A
Отделка полов на кухне	Плотник Паркет	100 10	A A
Отделка полов в прихожей	Плотник Паркет	100 15	A A

·      Установить различные профили загрузки для ресурса Подсобник.

Задание 7

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

Задание 8

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

Задание 9

Разработать функциональную модель декомпозиции работы информационно-справочной службы фирмы

Задание 10

Разработать функциональную модель работы информационной системы городского бюро медико-социальной экспертизы

Задание 11

Разработать функциональную модель декомпозиции работы информационной системы туристической фирмы

Задание 12

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

Задание 13

Разработать функциональную модель декомпозиции работы отдела бухгалтерии предприятия

Задание 14

Разработать функциональную модель работы переговорного пункта

Задание 15

Разработать функциональную модель декомпозиции работы регистратуры центральной районной больницы поселка городского типа

Задание 16

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

Задание 17

Разработать функциональную модель работы учебного отдела вуза

Задание 18

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

Задание 19

Разработать в среде Rational Rose модель информационной системы страховой компании

Задание 20

Разработать в среде Rational Rose модель информационной системы пункта проката видеофильмов

Задание 21

Разработать в среде Rational Rose модель информационной системы начисления сдельной заработной платы

Задание 22

Разработать в среде Rational Rose модель информационной системы учета транспортных перевозок

Задание 23

Разработать в среде Rational Rose модель информационной системы кассы автостанции

Задание 24

Разработать в среде Rational Rose модель информационной системы учета заявок клиентов торговой фирмы

Задание 25

Разработать в среде Rational Rose модель информационной системы приемной комиссии института

 

 

 

 

 

 

 

 

 

 

 

 

 

ГЛОССАРИЙ

Иструментальные средства разработки ПО	Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода Программы, отвечающего заданным требованиям.
Ruby\Watir	WATIR (англ. Web Application Testing in Ruby) — бесплатная библиотека для интерпретатора Ruby с открытым кодом, позволяющая тестировать веб-приложения. Библиотека WATIR понимает структуру веб-страниц и позволяет получить доступ к её элементам. Библиотека WATIR используется для написания сценариев тестирования веб-страниц. С помощью набора таких сценариев можно автоматизировать процесс тестирования веб-приложений.
Методология ARiS eEPC	ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера.
Методология DFD	DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Методология IDEF0	IDEF0  — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).
Отладка	Инструментальные средства отладки призваны дать разработчику максимально ясное представление о том, как работает его программа. И уже искусство разработчика состоит в том, чтобы, используя все имеющиеся в его распоряжении средства, быстро выявить ошибки. Набор средств отладки в Access широк: это и специальное меню Debug (Отладка), и во многом дублирующие его кнопки на панели инструментов, и специальные окна отладки. Далее кратко дается описание каждого средства.
Процессы IDEF3	DEF3 (англ. Integrated DEFinition for Process Description Capture Method) — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов представляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие

 

ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ/МДК

 

 

Основные источники:

1.     ГОСТ 2.105–79 Единая система конструкторской документации. Общие требования к текстовым документам.

2.     ГОСТ 2.105–95 Единая система конструкторской документации. Общие требования к текстовым документам.

3.     Валитов М. С., Валитов М. М. Инструментальные средства разработки программного обеспечения. М.:Академия ,2013

4.     Гамма Э. Приемы объектно-ориентированного проектирования. – СПб.:Питер, 2013

5.     Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем. М.:Феникс, 2011

6.     Голицына О.Л., Попов И.И., Партыка Т. Л. Программное обеспечение. М.:Форум, 2011

7.     Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектирование информационных систем. М.: Национальный открытый университет «ИНТУИТ», 2014

 

 

Информационные ресурсы сети Интернет:

1.           Интернет – университет http://www.intuit.ru/

2.            Программирование на JAVA, C++  http://www.kufas.ru/index.htm

3.           Сетевая энциклопедия Википедия http://ru.wikipedia.org/;

4.            Федеральный портал «Информационно-коммуникационные технологии в образовании» http://www.ict.edu.ru/;

5.            Федеральный портал «Российский портал открытого образования»;

6.            Федеральный портал «Российское образование» http://www.edu.ru/;

 

Журналы:

1.     Вестник компьютерных и информационных технологий.

2.     Компьютер-Пресс.

3.     Мир ПК.

4.     Полезные утилиты для разработчиков программного обеспечения.

5.     Практика функционального программирования.

6.     Программные продукты и системы.

 

 

 

 

 

 

 

Сапрунова Алёна Андреевна

Преподаватель Профессионального цикла

 

Государственное бюджетное профессиональное образовательное учреждение «Ставропольский региональный колледж»

 

 

 

 

 

УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС

ПО МДК 03.02 Инструментальные средства разработки программного обеспечения

 

 

 

основной профессиональной образовательной программы

по специальности

230115 Программирование в компьютерных системах

 

 

 

 

для студентов очной формы обучения