Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
9.Источники требований
Основным источником требований к информационной системе, безусловно, являются соображения, высказанные представителями Заказчика. В соответствие с иерархической моделью требований данная информация структурируется как минимум на 2 уровня: бизнес-требования и требования пользователей. Проблема состоит в том, что требования формулируются к создаваемой, ещё не существующей системе, т.е. по сути решается начальная подзадача задачи проектирования АИС, а представители Заказчика далеко не всегда бывают компетентны в данном вопросе. Поэтому, наряду с требованиями, высказанными Заказчиком, целесообразно собирать и требования от других совладельцев системы: сотрудников аналитической группы исполнителя, внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал рассматривается, как документ «Требования совладельцев»2. На требования совладельцев обычно не накладывается никаких специальных ограничений.
Продолжая рассуждения, начатые в предыдущей лекции, модель создаваемой информационной системы в определённой мере должна отражать модель ОС.
Поэтому другим важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную область. Это могут быть документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо просто документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии. Одной из немногих методологий, в которых специально выделяются рабочий поток делового моделирования, является Rational Unified Process.
Ещё одна альтернатива, используемая при выявлении требований – так называемые «лучшие практики», широко используемые в настоящее время в бизнес-консалтинге и при внедрении корпоративных информационных систем. Лучшие практики представляют собой описания моделей деятельности успешных компаний отрасли, используемые длительное время в сотнях и тысячах компаний по всему миру.
Подытоживая сказанное, отметим, что основными источниками, образующими «вход» процесса выявления требований, являются требования, высказанные совладельцами, как таковые или (и) артефакты, описывающие объект исследования. Однако, это – достаточно упрощённый взгляд: чтобы данные поступили «на вход», аналитики требований должны проделать немалую работу, связанную с подбором респондентов и информационных материалов, организацией интервью и т.д.
10.Статегии Выявления требований.Интервью.
Ключевой стратегией выявления требований было и остаётся интервью с экспертами.
В ставшей уже классической, но ничуть не утерявшей актуальность монографии Д.Марко [1] в процессе проведения интервью предлагается выделить три подчинённых процесса: подготовку, проведение интервью (опроса) и завершение. Ниже приводится краткий обзор рекомендаций Д.Марко с акцентом на выявление требований (в монографии даны рекомендации по интервьюированию с целью формирования модели объекта исследования).
1. Подготовка
Подготовка позволяет спланировать процесс опроса и выработать стратегию управления этим процессом. Важность подготовительного этапа вырастает, если респондент является «дефицитным» полезным ресурсом, например – президентом крупной компании.
При подготовке Д.Марко рекомендует следующие шаги:
При выборе собеседника для целей сбора требований определяющими являются две вещи:
Важно заранее оговорить цель встречи и ограничить беседу в пределах часа или менее. Практика показывает, что активное общение в процессе интервью, как правило, ограничивается часом. Если этого времени недостаточно, можно спланировать несколько встреч.
Полезными приёмами являются формирование программы беседы и ознакомление с ней респондента, подробное планирование беседы вплоть до записи подготовленных вопросов. Подготовленное таким образом интервью называют структурированным [2]. В дополнение к так построенному интервью автор [2] предлагает проводить неструктурированное интервью, «представляющее собой неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели». Цель такого интервью – пробудить респондента к креативу в области, в которой интервьюер недостаточно хорошо ориентируется.
2. Проведение опроса
Ниже приведёна цитата из [1], с некоторыми сокращениями и исключениям материала, не относящегося к АТ.
В проведении опроса самое важное – правильно организовать и поддерживать поток информации от эксперта к вам. Рекомендуется потратить время на обдумывание верного начала опроса, при сборе информации по возможности использовать записи, заканчивать разговор плавно. Обсудим подробнее каждый из этих пунктов.
Начиная разговор, не забудьте представиться и сформулировать цель встречи. Это поможет избежать недоразумений и даст беседе правильное направление. Кроме того, обговорите возможность ведения записей.
Затем сформулируйте первый вопрос. Помните, что первый вопрос часто задает тон всему разговору, поэтому хорошо продумайте его.
Собирайте информацию, делая записи обо всем (о специальных терминах, взаимосвязях между частями системы и т.п.) и ограничивая время беседы. Запишите SADT-функции и данные, попытайтесь набросать диаграмму. Поддерживайте поток информации, задавая вопросы, которые уточняют и подтверждают ответы.
Прежде всего, не возражайте.
Никогда не задавайте наводящих вопросов или вопросов с короткими ответами "да" или "нет". Вместо этого записывайте то, что вам говорят, и просите подвести итог или дать пояснения.
Вы получите от опроса больше, если вы дадите эксперту возможность говорить то, что он хочет сказать, а не то, что вы хотите услышать (конец цитаты).
3. Завершение
Следите за возникновением следующих ситуаций [1]:
Любая из этих причин - достаточное основание для завершения беседы.
Когда вы считаете нужным закончить опрос, завершайте беседу плавно. Кратко подытожьте основные пункты и сделайте обзор полученных сведений, которые могут быть опущены или неверно истолкованы. Договоритесь о времени следующей встречи, если она нужна, и получите рекомендации для ближайших опросов. Поставьте эксперта в известность, когда и как вы собираетесь использовать полученную информацию и когда вы пришлете ему материал на рецензирование.
Всегда оформляйте материалы опроса сразу же после встречи с экспертом. В этом случае немедленно возникает обратная связь, и вы минимизируете возможность потери важной информации.
Что нужно помнить при опросе
Следующие рекомендации помогают поддерживать непрерывность потока и достоверность информации, поступающей от эксперта [1]:
11.Статегии Выявления требований.Анкетирование.
Анкетирование – самый малозатратный для аналитика способ извлечения информации, он же – и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.
Недостатки анкетирования очевидны: респонденты часто бывают неспособны, либо слабо мотивированы в том, чтобы хорошо и информативно заполнить анкету. Велика вероятность получить неполную или вовсе ложную информацию. Преимущество – в том, что подготовка и анализ анкет требуют небольшой ресурс.
Л.Мацяшек [2] рекомендует формулировать в анкетах вопросы с замкнутым циклом ответов в одной из следующих трёх форм.
Многоальтернативные вопросы. Эта форма анкеты известна всем, кто когда либо проходил тестирование; может расширяться комментариями респондента в свободной форме.
Рейтинговые вопросы. Представляют предопределённый набор ответов на сформулированные вопросы. Используются такие значения, как «абсолютно согласен», «согласен», «отношусь нейтрально», «не согласен», «абсолютно не согласен», «не знаю».
Вопросы с ранжированием. Предусматривает ранжирование (упорядочивание) ответов путём присваивания им порядковых номеров, процентных значений и т.п.
12.Статегии Выявления требований.Наблюдение. Самостоятельное описание требований.
Наблюдение за работой моделируемой организационной системы - полезная стратегия получения информации (хотя, строго говоря, по результатам наблюдения можно получить модель ОС, а не модель АТ).
Различают пассивное и активное наблюдение. При активном наблюдении аналитик работает, как участник команды, что позволяет улучшить понимание процессов.
Через наблюдение, а возможно, и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговаривал с экспертами.
Недостатком этой стратегии является то, что наблюдатель, как и всякий «измерительный прибор», вносит помехи в результаты измерений: сотрудники организации, находясь «под колпаком» могут начать вести себя принципиально по другому, чем обычно.
Документы – хороший источник информации, потому что они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.
Если опытный аналитик уже исследовал большое число систем такого же типа, что и на предприятии внедрения, он обладает фундаментальными знаниями в соответствующей предметной области, относительно определенного класса систем. Авторы методологии SADT рекомендуют проводить самоопрос с тем, чтобы получить максимальную пользу от своих знаний.
По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо – основы для формирования технического задания.
Недостаток этой стратегии – опасность пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо – неформализованных знаний, эмпирических правил и процедур, широко используемых на практике, но не вошедших в документы.
13.Статегии Выявления требований.Совместные семинары. Прототипирование.
Помимо классического интервью «тет а тет», существует значительное количество методик, предполагающих широкое участие представителей Заказчика и Исполнителя.
Правила мозгового штурма предполагают полную раскрепощённость и свободу мнений, даже самых вычурных и на первый взгляд «бредовых». Первое правило мозгового штурма – «полный запрет на любую критику». Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.
Правила JAD-метода, считающегося одним из современных способов извлечения требований, были впервые сформулированы в конце 1970-х годов компанией IBM. Участники JAD-совещания:
Ведущий – специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.
Секретарь – стенографист встречи. Фиксирует её результаты на компьютере. Возможно применение CASE-средств.
Заказчики – пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения.
Разработчики – аналитики и другие участники проектной команды. Работают в большей части в пассивном режиме с целью наилучшего понимания проблемной области.
Совместные семинары, сохраняя все преимущества режима интервью, привносят дополнительные бонусы: работа в группе более продуктивна, группы быстрее обучаются, более склонны к квалифицированным заключениям, позволяют исключить многие ошибки.
Эта стратегия, очевидно, одна из самых затратных, однако она окупается за счёт меньшего количества ошибок и отказе от формализации в пользу живого общения, выработке общего языка и пр. Некоторые методологии (например, XP) зиждутся на постоянном тесном контакте между Заказчиком и Исполнителем и, если такой возможности нет – XP-проект просто не сможет состояться.
“Разъясняющие встречи” [3] или «запланированный мозговой штурм» – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.
Как и проведение интервью, организация семинара требует соблюдения правил, с которыми можно познакомиться в [2,4].
Прототипирование – ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в 10-Прототипирование требований). Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путём прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя даёт ещё больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
Метод RAD – один из наиболее известных способов быстро создавать прототипы5.
RAD базируется на следующих базовых принципах:
14.Проблемы выявления требований.Анализ требований.
15.Документирование и организация требований.
Способы документирования,типы документов.
16.Состав и распределение работ. Концепции экспулатации. Начальный план разработки ПО.
22.Свойства хорошей программы.
Удовлетворять функциональным требованиям. Прежде всего, хорошая программа должна делать то, что ожидает от нее заказчик – т.е. удовлетворять требованиям заказчика. Такие требования называют функциональными. Но кроме функциональных требований, существует еще ряд общих характеристик, которым в той или иной степени должна обладать каждая программа. Эти характеристики принято называть нефункциональными требованиями. К нефункциональным требованиям относят:
Следует отметить, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных усилий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя.
23.Профессиональные этические требования IT-специалиста. Кодекс этики IEEE/CS/AICM.
Развитие средств вычислительной техники, коммуникаций и программных систем (Internet, телекоммуникации, распределенные системы, IP телефония, компьютерные игры и обучающие программы) оказывает все большее воздействие на общество. Роль специалистов по программному обеспечению при этом все время возрастает. Они работают в определенном правовом и социальном окружении, находятся под действием, международных, национальных и местных законодательств.
Ясно, что программисты, как и специалисты других профессий, должны быть честными и порядочными людьми. Но вместе с тем, программисты не могут руководствоваться только моральными нормами или юридическими ограничениями, т.к. они обычно бывают связаны более тонкими профессиональными обязательствами:
В разработке таких этических обязательств ведущую роль играют профессиональные сообщества. Такие общества, как
совместно разработали и опубликовали IEEE-CS/ACM Software Engineering Code of Ethics and Professional Practices – Кодекс этики и профессиональной практики программной инженерии..
Члены этих организация принимают обязательство следовать этому кодексу в момент вступления в организацию
Кодекс содержит восемь Принципов, связанных с поведением и решениями, принимаемыми профессиональными программистами, включая практиков, преподавателей, менеджеров и руководителей высшего звена
Кодекс распространяется также на студентов и «подмастерьев», изучающих данную профессию
Кодекс имеет краткую и полную версии
Краткая версия кодекса
Программные инженеры должны добиваться, чтобы анализ, спецификация, проектирование, разработка, тестирование и сопровождение программного обеспечения стали полезной и уважаемой профессией. В соответствии с их приверженностью к процветанию, безопасности и благополучию общества, программные инженеры будут руководствоваться следующими Восемью Принципами
1. ОБЩЕСТВО
2. КЛИЕНТ И РАБОТОДАТЕЛЬ
3. ПРОДУКТ
4. СУЖДЕНИЕ
5. МЕНЕДЖМЕНТ
6. ПРОФЕССИЯ
4. КОЛЛЕГИ
8. ЛИЧНОСТЬ
Полная версия кодекса: IEEE-CS/ACM Software Engineering Ethics and Professional Practices. http://www.computer.org/tab/seprof/code.htm#Public
24.Технология,стандарт и сертификаты.
Происходит от греческого téchne (искусство, мастерство) и логия (знание, умение). Определяется как:
Иными словами – это подробное описание того, как надо изготовлять то или иное изделие и наука о составлении таких описаний.
Происходит от английского standard - норма, образец, мерило. Это:
Например: ГОСТ ЕСПД – единая система программной документации – документы, описывающие состав и структуру документации на разработку программ для ЭВМ (общее описание, техническое задание, эскизный проект, технический проект, описание применения). Типовые образцы – эталоны мер и весов (эталон метра, хранящийся в Париже в палате мер и весов).
Стандарт может быть разработан на:
Пример: Вузы работают в соответствии с государственными образовательными стандартами, представленными в виде паспортов специальностей.
Стандартизация распространяется на все сферы человеческой деятельности: науку, технику, промышленное и с.-х. производство, строительство, здравоохранение, транспорт и т.д. Шкаф проходит в дверь потому, что есть согласованные стандарты на размеры мебели и дверных проемов. Электрическая вилка втыкается в розетку по той же причине. Но можно вспомнить евро вилку и евро розетку.
Из истории стандартов: длина крепостной стены нижегородского кремля равна длине крепостной стены московского кремля. Также совпадают размеры Красной площади и площади Минина.
Сертификация в переводе с латыни означает "сделано верно". Для того чтобы убедиться в том, что продукт "сделан верно", надо знать:
Общепризнанным способом такого доказательства служит сертификация соответствия и заявление о соответствии.
Заявление поставщика о соответствии:
Заявление не является гарантией на соответствие стандарту. Заявление отражает готовность нести ответственность.
Сертификация соответствия:
Сертификация считается основным достоверным способом доказательства соответствия продукции (процесса, услуги) заданным требованиям (стандартам). Систему сертификации (в общем виде) составляют:
Системы сертификации могут действовать на национальном, региональном и международном уровнях.
25.Основные стандарты ПИ и кто их разрабатывает.
2 Терминология RUP
3 В нашем случае – группой аналитиков требований
4 На практике возможны ситуации, когда требование, сформулированное одним из представителей Заказчика, не подтверждается другим представителем, имеющим большие властные полномочия. Надо отчётливо понимать, что каждое требование в конечном итоге транслируется, с одной стороны, в компоненту информационной системы, а с другой – может быть выражено в определённом количестве денежных знаков, которые Заказчик должен будет выплатить Исполнителю по приёмке работы. Поэтому право формулировать требования и область компетенции того или иного эксперта должны быть формально оговорены внутренним документом Заказчика, с которым следует ознакомится до начала проведения интервью.
5 Хотя задачи RAD на этом не ограничиваются