«ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ДИСЦИПЛИНЫ (рабочая учебная программа дисциплины) Направление подготовки: 230100 Информатика и вычислительная техника Профили подготовки: 230101 ...»

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

Базовыми понятиями BPRявляются бизнес-система, бизнес-процесс, деловая процедура:

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

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

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

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

Реинжиниринг бизнес-процессов базируется на нескольких основных принципах:

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

• исполнители принимают самостоятельные решения, т.е.

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

• шаги процесса выполняются в естественном порядке;

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

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

• минимизируется количество согласований путем сокращения внешних точек контакта;

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

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

Свойства реинжиниринга:

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

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

3)приведение к значительным изменениям показателей деятельности (на порядок отличающихся от предыдущих).

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

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

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

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

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

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

';

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

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

"автоматизированный хаос", "асфальтировать дорожки, по которым коровы ходят на пастбище" 1. Несколько работ объединяются в одну (уплотнение по горизонтали) 2. исполнители принимают решения (уплотнение по вертикали) – в тех случаях когда принятие решения изолируется от самой работы, в новом процессе принятие решения становится частью работы– уменьшается число задержек, снижаются затраты на управление, повышается уровень работы с клиентами и расширение полномочий сотрудников 3. этапы процесса выполняются в естественном порядке – отказ от линейности, создание параллельных процессов 4. Должны быть варианты процессов для различных заказчиков, ситуаций и входных данных 5. Работа выполняется там, где ее целесообразно делать (закупка расходных материалов их потребителями) 6. снижение доли работ по проверке и контролю (групповой или отложенный контроль) 7. минимизация согласований 8. ответственный менеджер является единственной точкой контакта 9. сочетание централизованных и децентрализованных операций (преимущества автоматизации) От 50 до 70% BPR не достигают результата. Происходит это не от рисков, а от незнания. Сравнение рулетки и шахмат: рулетка – игра с высоким риском, так как исход в ней зависит от случая. В шахматах все зависит от умения, знаний и способностей.

Типичные ошибки:

1. попытка зафиксировать существующий процесс– меньшим числом людей те же функции, или внесение небольших изменений 2. внимание не фокусируется на бизнес –процессах 3. не принимаются во внимание ценности и убеждения людей 4. жесткие ограничения при постановке задачи– если руководство еще до начала жестко ограничивает круг решаемых задач или масштабы проведения BPR 5. попытки начать BPRснизу. Инициировать BPR может только руководитель высшего ранга – в силу полномочий, видения 6. недостаток ресурсов на проведение BPR ( и главные из них– время и внимание лучших сотрудников, включая личное участие руководства верхнего звена.) Недостаток ресурсов демонстрирует подчиненным отношение руководства к этому процессу.

7. попытка провести BPR, чтобы никого не обидеть Реинжиниринг АС – процесс перепроектирования системы, начиная со стадий реализации, логической модели, стадии технического проекта.

То есть процесс происходит в обратном направлении по отношению к процессам прямого проектирования.

Указанные виды реинжиниринга тесно связаны друг с другом, зависят один от другого.

Тема 6. Основные рабочие процессы: Разработка требований Программные требования – SoftwareRequirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.

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

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

(FunctionalandNon-functionalRequirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) UseСase.

Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.

Группа функциональных требований Бизнес-требования (BusinessRequirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

Пользовательские требования (UserRequirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (UseCases).

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

Группа нефункциональных требований (Non-FunctionalRequirements) Рассматривая бизнес-правила, как артефакты, относящиеся к области программных требований, можно отметить, почему БП относят к нефункциональным требованиям: Например, при написании определенного шага в сценарии usecase, используется ссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».

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

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

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

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

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

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

Интервьюирование – традиционный подход извлечения требований;

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

Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;

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

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

Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя ( типовая практика в eXtremeProgramming “on-sitecustomer” – “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных бизнес-процессах;

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

Анализ требований включает:

Обнаружение и разрешение конфликтов между требованиями;

Определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае - определение “scope” (или “bounds”), границ и содержания программного проекта;

Детализация системных требований для установления программных требований;

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

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

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

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ Р ИСО МЭК 12207). Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:

Архитектурный или высокоуровневый дизайн (software architectural design, top-leveldesign) – описание высокоуровневой структуры и организации компонентов системы;

Детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.

Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент;

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

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

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

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

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

2 Связанность и соединение (Couplingand Cohesion) Связанность (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями. Соединение (Cohesion) – определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь.

Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и “соединение” могут рассматриваться как степень самодостаточности или ее отсутствия (coupling) и функциональная зависимость (cohesion), соответственно.

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

(Encapsulation/informationhiding).

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

5 Разделение интерфейса и реализации (Separation of interface and implementation) Данная техника предполагает определение компонента через специфицирование интерфейса, известного (описанного) и доступного клиентам (или другим компонентам), от непосредственных деталей реализации.

6 Достаточность, полнота и простота (Sufficiency, completeness and primitiviness) Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того. То есть не включают функциональность, отсутствующую в модели.

Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых практик (best practices) методологий гибкого моделирования и экстремального программирования, где “все, что надо, но ни граммом больше” лежит в основе самой концепции “прагматичного” подхода (и на стадии моделирования, и в отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

Структура и архитектура программного обеспечения (Software В строгом значении архитектура программного обеспечения (software architecture) – описание подсистем и компонент программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется.

В середине 90-х, на волне распространения клиент-серверного подхода и начала его трансформации в “многозвенный клиент-сервер”, призванный обеспечить централизованное развертывание и управление общей (для клиентских приложений) бизнес-логикой, вопросы организации архитектуры программного обеспечения стали складываться в самостоятельную и достаточно обширную дисциплину. В результате, сформировалась точка зрения на архитектуру не только в приложении к конкретной программной системе, но и развился взгляд на архитектуру, как на приложение общих (generic) принципов организации программных компонент. В итоге, уже на сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый комплекс подходов и созданы (и продолжают создаваться и развиваться) различные архитектурные “фреймворки”, то есть систематизированные комплексы методов, практик и инструментов, призванные в той или иной степени формализовать имеющийся в индустрии опыт (как положительный – например, design patterns, так и отрицательный – например, anti-patterns).

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

Шесть строк таблицы отражают шесть уровней представления системы:

технологическая (физическая) модель;

детальная реализация (часто - поблочная и выполняемая субподрядчиком);

представление пользователя.

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

Архитектурная (в широком смысле слова) наука предлагает нам полную модель Захмана (Известные архитектурные модели (строго говоря, нотации описания архитектурных моделей) легко укладываются в эту модель. В свете введенных нами определений строки и столбцы модели Захмана являются проекциями: строки — с точки зрения групп заинтересованных лиц, столбцы — с точки зрения областей рассмотрения (что, кто, как, когда, где и зачем).

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

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

Информационное обеспечение АС, как известно, состоит из внемашинной и внутимашинной компонент.

Внутримашинное ИО содержит массивы данных на машинных носителях и программу организации доступа к этим данным.

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

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

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

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

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

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

Для повышения эффективности системы документооборота используются следующие подходы:

Проведение унификации и стандартизации документов Внедрение электронного документооборота.

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

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

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

к унифицированным системам документации;

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

к составу и структуре реквизитов и показателей;

унифицированных форм документов.

В настоящее время разработаны следующие виды УСД на межотраслевом уровне:

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

Преимущества экранных форм:

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

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

Тема 8.Основные рабочие процессы: реализация Синонимы: конструирование, программирование, кодирование (softwareconstruction) описывает детальное создание рабочей программной системы посредством комбинации кодирования, верификации (проверки), модульного тестирования (unittesting), интеграционного тестирования и отладки.

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

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

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

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

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

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

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

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

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

Ожидание изменений поддерживается рядом техник.

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

Среди техник, направленных на достижение такого результата конструирования:

обзор, оценка кода (codereview);

модульное тестирование (unit-testing);

структурирование кода для и совместно с применениям автоматизированных средств тестирования (automatedtesting);

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

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

коммуникационные методы (например, стандарты форматов документов и оформления содержания);

языки программирования и соответствующие стили кодирования (например, JavaLanguageSpecification, являющийся частью стандартной документации JDK – JavaDevelopmentKit и JavaStyleGuide, предлагающий общий стиль кодирования для языка программирования Java);

платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или.NET Framework SDK, Software Development Kit);

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

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

Стандарты создаются разными источниками, например, консорциумом OMG – Object Management Group (в частности. Стандарты CORBA, UML, MDA, …), международными организациями по стандартизации такими, как ISO/IEC, IEEE, TMF, …, производителями платформ, операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA.), производителями инструментов, систем управления базами данных и т. п.

(Borland, IBM, Microsoft, Sun, Oracle). Понимание этого факта позволяет определить достаточный и полный набор стандартов, применяемых в проектной команде или организации в целом.

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

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

Соответственно, применение измерений в отношении кода становится тем инструментом, который влияет и на управление и на сам код.

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

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

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

Тестировании в конструировании обычно включает подмножество видов тестирования, описанных в области знаний “Тестирование программного обеспечения” (Software Testing). Например, тестирование в конструировании обычно не включает системного тестирования, нагрузочного тестирования, usability-тестирования (оценки прозрачности использования) и других видов тестовой деятельности.

Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.

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

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

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

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

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

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

Основные термины Определение тестирования и связанной терминологии достаточно полно даётся в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90 (Standard Glossary of Software Engineering Terminology Динамичность (dynamic) этот термин подразумевает, что тестирование всегда предполагает выполнение тестируемой программы с заданными входными данными. При этом величины, задаваемые на вход тестируемому программному обеспечению, не всегда достаточны для определения теста. Сложность и недетерминированность систем приводит к тому, что система может по разному реагировать на одни и те же входные параметры, в зависимости от состояния системы.

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

Выбор (selection) – многие предлагаемые техники тестирования отличаются друг от друга в том, как выбираются сценарии тестирования.

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

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

Ожидаемое поведение (expected behaviour). Хотя это не всегда легко, все же необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а какое – нет. В противном случае, усилия по тестированию – бесполезны. Наблюдаемое поведение может рассматриваться в контексте пользовательских ожиданий (подразумевая “тестирования для проверки” – testing for validation), спецификации (“тестирование для аттестации” – testing for verification) или, наконец, в контексте предсказанного поведения на основе неявных требований или обоснованных ожиданий.

Недостатки и сбои (Faultsvs. Failures). В литературе, посвященной программной инженерии, встречается множество терминов, описывающих нарушение функционирования программных систем – недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. Важно чётко разделять причину нарушения работы прикладных систем, обычно описываемую терминами недостаток или дефект, и наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям.

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

Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.

Модульное тестирование (Unit testing).Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

Интеграционное тестирование (Integration testing). Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.

Классические стратегии интеграционного тестирования – “сверхувниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисноориентированных архитектурах (SOA).

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

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

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

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

Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или неявно) и различным уровнем точности.

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

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

Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования:

Приёмочное тестирование (Acceptance/qualification testing).

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

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

Установочное тестирование (Installation testing). Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.

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

Данный вид тестирования не может быть заранее спланирован.

Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing). Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.

Достижение и оценка надежности (Reliability achievement and evaluation). Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности. ”.

Регрессионное тестирование (Regression testing). Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.

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

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

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

Сравнительное тестирование (Back-to-backtesting). Единичный набор тестов, позволяющих сравнить две версии системы.

Восстановительные тесты (Recoverytesting). Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система.

Конфигурационное тестирование (Configuration testing). В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.

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

Разработка, управляемая тестированием (Test-driven development).

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

В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основе функциональных возможностей). TDD может естественно рассматриваться как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методов гибкой разработки.

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

Технология проектирования ИС – это совокупность методологии и средств проектирования, а также методов и средств организации проектирования Технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего стало бы ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.

Предметом любой выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла ЭИС К основным требованиям, предъявляемым к выбираемой технологии проектирования, относятся следующие:

• созданный с помощью этой технологии проект должен отвечать требованиям заказчика;

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

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

• технология должна способствовать росту производительности труда проектировщика;

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

• технология должна способствовать простому ведению ной документации.

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

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

Методы проектирования ЭИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

Так, по степени автоматизации методы проектирования разделяются на методы:

• ручного проектирования, при котором проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование -– на алгоритмических языках;

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

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

• оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ЭИС;

• типового проектирования, предполагающего конфигурацию ЭИС из готовых типовых проектных решений (программных модулей).

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

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

По степени адаптивности проектных решений методы проектирования классифицируются на методы:

• реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

• параметризации, когда проектные решения настраиваются (перегенерируются) в соответствии с изменяемыми параметрами;

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

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

Индустриальная технология, в свою очередь, разбивается на два подкласса:

автоматизированное (с использованием CASE– технологий) типовое (параметрически – ориентированное или модельно– ориентированное ) проектирование.

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

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

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

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

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

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

Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС.

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

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

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

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

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

модульное проектирование;

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

сокращение затрат на проектирование и программирование взаимосвязанных компонентов;

хорошее документирование отображаемых процессов обработки информации.

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

В качестве примеров широко распространенных функциональных ППП можно назвать: 1С "Предприятие" (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), "Фолио - Склад" (автоматизация складских операций), ProjectExpert (бизнеспланирование), ИНЭК (финансовый анализ) и др.

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

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

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

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

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

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

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

Каноническое проектирование ИС отражает особенности ручной технологии индивидуального проектирования, получившей свое развитие в 80-х годах прошлого столетия и до сих пор не утратившей свое значение.

Основано на использовании каскадной модели жизненного цикла ИС и регламентируется в отечественной практике стандартами группы 34:

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управ ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.

автоматизированной системы (Взамен ГОСТ 24.201-85) ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

Согласно канонической модели процесс создания ИС принято разбивать на следующие стадии:

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

формирование требований;

изучение объекта автоматизации;

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

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

создание и утверждение технико-экономического обоснования;

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

2. Проектирование Предварительное проектирование:

выбор проектных решений по всем аспектам разработки информационной системы;

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

оформление и утверждение технического проекта.

Детальное проектирование:

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

корректировка структур баз данных;

создание документации на поставку и установку программных продуктов;

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

создание документации на поставку и установку технических средств;

разработка технорабочего проекта информационной системы.

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

разработка, тестирование и доводка программ;

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

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

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

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

обучение и сертифицирование персонала;

проведение опытной эксплуатации всех компонентов и системы в целом;

сдача в эксплуатацию и подписание актов приемки-сдачи работ.

5. Эксплуатация информационной системы повседневная эксплуатация;

сопровождение программных, технических средств и всего проекта.

Технология RUP (RationalUnifiedProcess) разработана компанией RationalSoftware. Она ориентирована на использование универсального языка объектно-ориентированного моделирования UML, являющегося фактическим стандартом в данной области (см. главу 3).

Общий вид процесса представляет RUP в двух измерениях:

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

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

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

начальная стадия (inception);

стадия уточнения (elaboration);

стадия конструирования (construction);

стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

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

Начальная стадия. Она может принимать множество разных форм.

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

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

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

Результатами начальной стадии являются:

общее описание системы (основные требования к проекту, его характеристики и ограничения);

начальная диаграмма вариантов использования (степень готовности - 10 - 20%);

начальный проектный глоссарий (словарь терминов);

начальный бизнес-план;

план проекта, отражающий стадии и итерации;

один прототип или несколько.

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

Результатами стадии уточнения являются:

диаграмма вариантов использования (завершенная по крайней мере на 80%), определяющих требования к системе;

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

описание базовой архитектуры будущей системы;

работающий прототип;

уточненный бизнес-план;

план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.

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

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

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

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

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

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

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

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

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

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

Назначение этого процесса состоит в снижении степени риска.

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

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

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

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

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

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

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

ПО, интегрированное на требуемых платформах;

руководства пользователя;

описание текущей реализации.

Стадия ввода в действие. Назначение этой стадии — передача готового продукта в распоряжение пользователей. Данная стадия включает:

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

параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

конвертирование баз данных;

оптимизацию производительности;

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

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

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

На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсолютно необходимой). Здесь только вылавливаются ошибки. Хорошим примером для стадии ввода в действие может служить период времени между выпуском бета-версии и окончательной версии продукта.

Статический аспект Статический аспект RUP характеризуют четыре основных элемента:

исполнители;

результаты деятельности;

рабочие процессы.

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

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

Любое действие должно являться элементом процесса планирования.

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

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

В рамках RUP определены шесть основных процессов:

построение бизнес-моделей;

определение требований;

анализ и проектирование;

реализация;

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

развертывание и три вспомогательных процесса:

управление конфигурацией;

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

создание инфраструктуры (environment).

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

База знаний включает следующие компоненты:

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

наставления по использованию инструментальных средств, входящих в состав Rational Suite;

примеры и шаблоны проектных решений для Rational Rose;

шаблоны проектной документации для SoDa;

шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;

планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью специального набора инструментов и шаблонов Development Kit. База знаний имеет формат гипертекста (HTML – Hyper Text Markup Language — стандартный язык для создания страниц Интернет). Доступ к ней может осуществляться с помощью Microsoft Internet Explorer или Netscape Navigator. Такой формат допускает как индивидуальное, так и коллективное использование базы знаний в сети Интранет.

5.3.1 Перечень рекомендуемых лабораторных работ 1. Лабораторная работа №1.Построение функциональной модели объекта автоматизации «AS-IS»

2. Лабораторная работа №2. Анализ функциональной модели.

Формулирование требований к автоматизированной системе Применяемые интерактивные формы обучения на лабораторных занятиях (не менее 4часов) Проектный метод (работа организуемся в виде проекта, задаются этапы и сроки разработки)– лабораторные работы №1-2(1 час);

Разбор конкретных ситуаций – модели строятся на основе реально существующих процессов – лабораторные работы №1-2 (0,5 часа);

Работа в команде (групповая разработка моделей, разделение задачи внутри группы)– лабораторные работы №1-2 (0,5 часа).

Методические указания по выполнению лабораторных 1. Лабораторная работа №1.Построение функциональной модели объекта автоматизации «AS-IS»

Цель лабораторной работы Целью выполнения лабораторной работы является ознакомление с принципами и стратегиями построения моделей в стандарте IDEF0.

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

Знать принципы построения моделей в стандарте IDEF0;

Знать стратегии декомпозиции и сферу их применения;

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

Индивидуальные задания Построить модель «AS-IS» в стандарте IDEF0 для одного из перечисленных ниже объектов автоматизации для определенного горизонта времени.

1. Школа 2. Детский сад 3. Спортивная школа 4. Парикмахерская 5. Салон красоты 6. Компьютерный клуб 7. Фитнес-клуб 8. Автосервис 9. АЗС 10. Ночной клуб 11. Библиотека 12. Супермаркет 13. Агентство недвижимости 14. Кинотеатр 15. Турагенство 16. Аптека 17. Поликлиника 18. Склад 19. Прокат видеофильмов 20. Гостиница 21. Собственный вариант Требования к результату выполнения лабораторной работы Функциональная модель должна быть выполнена с помощью CASE-– средства BPWin. На первом уровне декомпозиции необходимо использовать стратегию «по системным функциям», на последующих – «по жизненному циклу» и функциональную. На каждой диаграмме должна быть помечена используемая стратегия.

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

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

Технология выполнения лабораторной работы Ознакомиться с теоретическим материалом Выбрать вариант задания и временной горизонт модели.

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

Защитить лабораторную работу.

1. Лабораторная работа №2. Анализ функциональной модели.

Формулирование требований к автоматизированной системе Цель лабораторной работы Целью выполнения лабораторной работы является ознакомление студентов с основами анализа построенных функциональных моделей ASIS и процессом создания моделей требований к автоматизированной системе (АС).

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

Ознакомиться с содержанием этапа анализа функциональных Уметь формулировать бизнес-требования;

Уметь выделять классы пользователей и требования пользователей;

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

Знать виды диаграмм языка UML;

Моделировать требования с помощью CASE-средстваEnterprise Architect;

Знать содержание стандарта ГОСТ 34.602-89 Информационная технология. Техническое задание на разработку АС.

Индивидуальные задания Проанализировать разработанную в лабораторной работе № функциональную модель AS–IS с точки зрения возможности автоматизации функций и разработать требования к будущей автоматизированной системе в виде модели требований в среде Enterprise Architect 1. Школа 2. Детский сад 3. Спортивная школа 4. Парикмахерская 5. Салон красоты 6. Компьютерный клуб 7. Фитнес-клуб 8. Автосервис 9. АЗС 10. Ночной клуб 11. Библиотека 12. Супермаркет 13. Агентство недвижимости 14. Кинотеатр 15. Турагенство 16. Аптека 17. Поликлиника 18. Склад 19. Прокат видеофильмов 20. Гостиница 21. Собственный вариант Требования к результату выполнения лабораторной работы Требования к АС представить в среде Enterprise Architect в виде модели, содержащей разделы Технического задания в соответствии с ГОСТ 34.602-89 «Информационная технология.

Техническое задание на разработку АС»;

Бизнес– требования должны быть сформулированы в виде модели Классы пользователей должны быть описаны в модели «Пользователи системы» раздела «Границы системы»;

Требования пользователей должны быть отображены как диаграммы Use Case языка UML;

Функциональные требования должны быть представлены в моделях «Типовые функциональные требования», «Схема функциональной структуры», «Описание автоматизированных Нефункциональные требования описать в соответствующих пакетах модели «Нефункциональные требования»;

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

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

Технология выполнения лабораторной работы Ознакомиться с теоретическим материалом Ознакомиться с возможностями CASE-средства Enterprise Проанализировать разработанную ранее модель AS-IS с точки зрения возможности автоматизации Создать модель требований в соответствии с Инструкцией Защитить лабораторную работу.

5.4 Краткое описание практических занятий 5.4.1 Перечень практических занятий не предусмотрены 5.5 Краткое описание видов самостоятельной работы 5.5.1 Общий перечень видов самостоятельной работы 1. Самостоятельное изучение разделов дисциплины.

2. Выполнение контрольной работы.

3. Подготовка к лабораторным работам и оформление отчетов.

4. Подготовка к зачёту.

5.5.2 Методические рекомендации по выполнению каждого вида 1. Самостоятельное изучение разделов дисциплины Тема 1.3. Классификация информационных систем Тема 1.5. Жизненный цикл систем Тема 2.2 Реинжиниринг бизнес-процессов Тема 2.5Конструирование Тема 3.1 Требования к технологиям проектирования Тема 3.2 Каноническое проектирование ИС Тема 3.3.Типовое проектирование ИС Тема 3.5.Технология RUP 2. Выполнение контрольной работы. Проектирование информационных технологических процессов. Стандарт DFD (DataFlow Diagram).

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

Знать предназначение стандартаDFD;

Понимать место ИТ в структуре информационных систем;

Знать принципы отображения этапов информационных технологий средствами стандарта DFD.

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

1. Разработка сайта 2. Открытие электронного почтового ящика 3. Подключение к WEB—стриму 4. Заключение договора с провайдером 5. Администрирование прав доступа 6. Проведение олимпиад 7. Сдача сессии 8. Движение контингента студентов в вузе (зачисление, перевод с курса на курс, перевод из вуза в вуз, отчисление, оформление академического отпуска и т.д.) 9. Получение водительских прав 10. Поиск работы 11. Получение паспорта 12. Аренда жилья 13. Приватизация квартиры 14. Собственный вариант Требования к результату выполнения лабораторной работы Информационный технологический процесс должен быть представлен средствами графического редактора VISIO (SoftWare/Gane-Sarson).

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

Технология выполнения контрольной работы 1. Ознакомиться с теоретическим материалом.

2. Ознакомиться с инструментами графического редактора VISIO (SoftWare\Gane-Sarson).

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

4. Подготовитьотчет и защитить лабораторную работу.

3.Подготовка к лабораторным работам;

Цель: освоение CASE-средств, необходимых для выполнения лабораторных работ.

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

Отчет должен содержать титульный лист, цель работы, постановку задачи, результаты работы, скриншоты, выводы.

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

2. Оформление отчетов по лабораторным работам;

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

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

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

Зачет по дисциплине ставится при наличии защищенных лабораторных работ, запланированных в семестре.

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

Контрольно-измерительные материалы и другие оценочные средства для итоговой аттестации по дисциплине Пример теста Какие этапы не входят в разработку ИС:

Требования пользователей Ликвидация Реализация Модернизация Проектирование Внешние косвенные клиенты Находятся вне предприятия Находятся внутри предприятия Поставщики Отметьте лишнее в стадии анализа: