маршрутезатор. Лекции АИС УФИС 2011 студентам. Лекция 1 Введение
 Скачать 1.14 Mb.
|
|
Лекция 43 Математическое моделирование является наиболее эффективным при построении АИС. Его применение дает возможность оперативно и аргументированно решать на всех этапах жизненного цикла научно-технические задачи: оценки рыночной перспективности создаваемых систем и возможностей поставщиков, организации эффективных систем менеджмента качества; обоснования системотехнического облика и количественных требований технического задания к характеристикам систем, технологиям их создания и функционирования, к квалификации разработчиков и пользователей; оценки выполнимости требований заказчика и степени их удовлетворенности по мере развития проекта и в процессе функционирования системы; оценки и обоснования технических решений по проектированию, анализа и снижения рисков при управлении проектами; исследования вопросов защищенности систем от потенциальных угроз безопасности, в том числе от террористических угроз и угроз информационной безопасности, выявления «узких мест» и уязвимости системы и рациональных путей их устранения с указанием условий, когда это принципиально возможно; оценки качества систем и обоснования их эффективной эксплуатации и другие. 3.2.2. Методика оценки и расчет экономической эффективности создаваемой АИС Проектирование технологического процесса обработки данных в АИС заключается в определении взаимосвязанной совокупности технологических операций обработки данных и рассредоточении их по рабочим местам специалистов — участников информационно-вычислительного процесса (сотрудников вычислительного центра и пользователей АИС) с учетом состава технических средств и их пространственного размещения. К типовым операциям обработки относят: сбор и регистрацию данных, перенос данных на машинные носителя, ввод, компоновку и контроль данных, накопление данных, сортировку данных, обработку данных, корректировку данных, реструктуризацию данных в базе, вывод результатной информации. Способы реализационных операций обработки данных и комбинации их увязки в единый технологический процесс определяются технологическим оборудованием и требованиями к объемно-временным параметрам и формам получения результатной информации. При проектировании технологии обработки данных учитываются специфические пожелания заказчика и традиции индустрии обработки данных в данной предметной отрасли. Кроме того, разрабатываются технологические инструкции по организации движения входных документов и данных, по обработке и использованию результатной информации (документов, видеограмм), а также подготавливаются проекты инструкций по эксплуатации на каждый вид оборудования и проекты должностных инструкций. В заключение проводится расчет экономической эффективности проектируемой АИС, его экспертиза и подготавливается проектный документ с таким же названием. Документ «Расчет экономической эффективности» содержит следующие разделы: исходные данные для расчета; расчет эффективности системы; результаты расчета. Для оценки результатов деятельности (применения) системы используется понятие «эффективность». Под эффективностью системы будем понимать степень соответствия реальных результатов деятельности (применения, использования) системы требуемым или степень достижения множества возможных целей. Под целью будем понимать желаемое (требуемое) множество состояний объекта управления и элементов окружающей среды, 206 на которые активно воздействует объект управления в определенные моменты времени. Процесс (от лат. processus — продвижение) — совокупность последовательных действий для достижения какого-либо результата. Этап (от франц. etape — промежуток времени, отмеченный каким-либо событием) — часть процесса, завершающаяся достижением поставленной промежуточной цели за конечный интервал времени. Таким образом, процесс функционирования технической системы есть процесс ее создания и применения (эксплуатации), следовательно, совершенствование процессов функционирования должно также осуществляться в процессе создания и эксплуатации. Формально процесс функционирования технической системы может быть представлен следующим образом. Здесь под вычислительным комплексом (ВК) будем понимать в широком смысле совокупность технических и программных средств, образующих узел системы распределенной обработки данных (СРОД). Рассмотрим зависимость основных характеристик информационных технологий распределенной обработки данных от характеристик ИП и их совокупностей. АИС, как и любые сложные системы, предназначены для выполнения некоторого круга ИВР и имеют вполне определенные цели и задачи. В этом свете качество информационных технологий РОД, на базе которых строится данная АИС, должно оцениваться с помощью показателей эффективности, т. е. характеристик, определяющих степень приспособленности АИС к решению возложенных на нее задач. Тем самым показатель эффективности определяется процессом функционирования системы, т. е. является функционалом от процесса функционирования, так что множество процессов функционирования, различающихся условиями и режимами работы, отображается на множестве значений показателя эффективности. Для сложных систем, к каким относятся СРОД, невозможно выделить единственный показатель эффективности, позволяющий охарактеризовать все интересующие пользователей аспекты функционирования системы. Рассмотрим в качестве иллюстрации совокупность показателей эффективности, используемую для оценки функционирования некоторых специальных АИС и отражающую определенные выше свойства: оперативность управления; качество отработки управленческих решений; устойчивость управления; непрерывность управления. На уровне ВК продолжительность ИП зависит от затрат на обмен информацией с внешних запоминающих устройств (ВЗУ). Последние же определяются тем, в какой памяти хранятся данные и программы, необходимые для выполнения соответствующих ИВР. Для уровня устройства ВК продолжительность ИП определяется, в основном, затратами на поиск информации. Сокращение этих затрат за счет рационального распределения информации в ЗУ способствует значительному уменьшению продолжительности ИП. Таким образом, продолжительность ИП на каждом из уровней их представления связана с затратами на передачу и обмен информацией и на ее поиск. Чем выше затраты, тем больше в среднем продолжительность ИП. Величина этих затрат является переменной и зависит от принятых решений по построению и организации функционирования СРОД в рамках выбранной информационной технологии. Лекция 44-45 3.3. Стандартизация и сертификация АИС Современный этап создания и развития отечественных АИС характеризуется следующими условиями, способствующими снижению их качества: жесткой конкурентной борьбой (в том числе и с зарубежными фирмами и совместными предприятиями) за отечественный рынок сбыта информации; расширением областей функционального применения, совершенствованием и развитием существующих АИС, объективной необходимостью существенного увеличения объема перерабатываемой и передаваемой информации с использованием средств автоматизации; • использованием непроверенного ПО (в том числе зарубежного общесистемного и технологического ПО ввиду недостаточности качественных отечественных аналогов), представляемого в виде «черного ящика» без исходных текстов и являющегося по этой причине потенциальным обладателем закладных элементов, создающих угрозу информационной безопасности АИС. Сертификация — подтверждение достигнутого качества независимыми экспертами с выдачей сертификата соответствия требованиям стандартов. Однако вследствие их новизны, высокой сложности объектов сертификации и многообразия показателей качества появился ряд особенностей этих проблем: научно-методические проблемы состоят в создании эффективных по затратам ресурсов методов сертификационных испытаний, гарантирующих достоверное определение заданных показателей качества функционирования АИС и соответствие документации; технологические проблемы заключаются в обеспечении реализации методов испытаний АИС средствами автоматизации, тестирования и организации регламентированных проверок качества программ, данных и документации на разных этапах их создания и при сертификационных испытаниях; проблемы стандартизации и нормативной документации сводятся к созданию, последующему выбору и адаптации документов, применяемых для сертификационных испытаний АИС; организационные проблемы состоят в создании международных, государственных и ведомственных органов, ответственных за сертификацию АИС, в определении их прав и обязанностей, в оснащении их необходимыми нормативно-методическими и инструментально-технологическими средствами; экономические проблемы сводятся к выявлению, оценке и применению экономически эффективных методов испытаний АИС, обеспечивающих заданную достоверность определения качества их функционирования, к разработке экономических механизмов взаимодействия организаций и специалистов по сертификации с разработчиками и заказчиками АИС; правовые проблемы заключаются, прежде всего, в создании юридических механизмов процессов сертификации и использования их результатов, создании нормативов, правил взаимодействия и распределения экономической и юридической ответственности между поставщиками, испытателями и потребителями (заказчиками) АИС за несоответствие реальных показателей качества гарантированным характеристикам сертифицированных изделий. 3.3.1 Организационно-правовые документы в области стандартизации и сертификации. Обзор существующих правовых документов Стандарты, регламентирующие обеспечение адекватности функционирования автоматизированных информационных систем К стандартам, регламентирующим обеспечение адекватности функционирования АИС, отнесены стандарты в области систем качества, стандарты, регламентирующие управление проектированием, разработку и тестирование ПО, а также документирование АИС. Стандарты в области систем качества, реализуемых на предприятиях-разработчиках К стандартам в области систем качества относятся международные стандарты: • ISO 08402:1986. Качество. Словарь; ISO 9000:1987. Система качества. Общее руководство качеством и стандарты по обеспечению качества; ISO 9001:1987. Система качества. Модель для обеспечения качества при проектировании и (или) разработке, производстве, монтаже и обслуживании; ISO 9002:1987. Система качества. Общие мероприятия по обеспечению качества при производстве и монтаже изделий; ISO 9003:1987. Система качества. Общие мероприятия по обеспечению качества при окончательном их контроле и испытаниях; ISO 9004:1987. Система качества. Общие мероприятия по обеспечению качества при внедрении и общем руководстве системой качества с целью производства конкурентоспособной продукции; ISO 10011-1:1990. Руководящие указания по проверке системы качества. Часть 1: Проверка. В России соответствующие стандарты серии ISO 9000 действуют без принципиальных изменений в рамках ГОСТ 40.9000-9004:1988 г. Стандарт ISO 8402 содержит основные термины, относящиеся к понятию качества, которые рекомендуются для их применения к продукции и услугам, для разработки и использования стандартов по качеству, а также для установления взаимопонимания в международных связях. Стандарты серии ISO 9000 представляют собой руководящие указания по выбору и применению основных понятий качества, принципиальных концепций и критериев, раскрытых более подробно в стандартах ISO 9001-9004. В головном стандарте выделены три задачи в решении проблемы качества: достижение и поддержка качества продукции или услуг на уровне, удовлетворяющем потребителей; обеспечение руководству уверенности в достижении и поддержке качества на заданном уровне; обеспечение потребителю уверенности в том, что заданное качество достигается или будет достигнуто. Головной стандарт группы ISO 9001 помогает оценивать способность поставщика не только успешно проектировать изделия, но также производить их и проверять. В стандарте подробно изложены требования к системе качества и ее компонентам. Определена ответственность руководства за политику и организацию в области качества, представлены общие требования к управлению проектированием, документацией и проведением испытаний. В стандартах ISO 9002-9004 регламентированы общие мероприятия по обеспечению качества: при производстве и монтаже изделий (9002), при окончательном их контроле и испытаниях (9003), при внедрении и общем руководстве системой качества с целью производства конкурентоспособной продукции (9004). Особое значение при разработке АИС имеет стандарт ISO 9000-3: 1991. Общее руководство качества и стандарты по обеспечению качества. Часть 3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. В стандарте ISO 10011-1 изложены указания по проверке системы качества. Стандарты, регламентирующие управление проектированием программного обеспечения К стандартам, регламентирующим управление проектированием ПО, относятся: ANSI/IEEE 983-1986. Руководство по планированию обеспечения качества программных средств; ISO 9126:1991. ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению; ГОСТ 28195-89. Оценка качества программных средств. Общие положения; ГОСТ 28806-90. Качество программных средств. Термины и определения; ГОСТ 19781-90. Обеспечение систем обработки информации. Термины и определения; ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании АС; ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. Стандарты, регламентирующие документирование Создание и применение АС сопровождается документированием обеспечения интерфейса с пользователями, а также возможности их освоения и функционального совершенствования. Комплексы отечественных стандартов, регламентирующие документирование АС на различных стадиях его создания, представляют во многом морально устаревшие стандарты серий «Информационная технология», «Единая система стандартов автоматизированной системы управления», «Единая система программной документации»: ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; ГОСТ 34.201-89 Информационная технология, комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем; РД 50-34.698-90 Информационная технология. Комплекс стандартов и руководящих указаний на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов; ГОСТ 24.101-80 Система технической документации на АСУ. Виды и комплектность документов; ГОСТ 24.102-80 Система технической документации на АСУ. Обозначение документов; ГОСТ 24.103-84 Единая система стандартов автоматизированных систем управления. Автоматизированные системы управления. Основные положения; ГОСТ 24.202-80 Система технической документации на АСУ. Требования к содержанию документа «Технико-экономическое обоснование создания АСУ»; ГОСТ 24.203-80 Система технической документации на АСУ. Требования к содержанию общесистемных документов; ГОСТ 24.204-80 Система технической документации на АСУ. Требования к содержанию документа «Описание постановки задачи»; ГОСТ 24.205-80 Система технической документации на АСУ. Требования к содержанию документов по информационному обеспечению; ГОСТ 24.206-80 Система технической документации на АСУ. Требования к содержанию документов по техническому обеспечению; ГОСТ 24.207-80 Система технической документации на АСУ. Требования к содержанию документов по программному обеспечению; ГОСТ 24.208-80 Система технической документации на АСУ. Требования к содержанию документов стадии «Ввод в эксплуатацию»; ГОСТ 24.209-80 Система технической документации на АСУ. Требования к содержанию документов по организационному обеспечению; ГОСТ 24.210-82 Система технической документации на АСУ. Требования к содержанию документов по функциональной части; ГОСТ 24.211-82 Система технической документации на АСУ. Требования к содержанию документа «Описание алгоритма»; ГОСТ 24.301-80 Система технической документации на АСУ. Общие требования к выполнению текстовых документов; ГОСТ 24.302-80 Система технической документации на АСУ. Общие требования к выполнению схем; ГОСТ 24.303-80 Система технической документации на АСУ. Обозначения условные графические технических средств; ГОСТ 24.304-82 Система технической документации на АСУ. Требования к выполнению чертежей; ГОСТ 24.401-80 Система технической документации на АСУ. Внесение изменений; ГОСТ 24.401-80 Система технической документации на АСУ. Учет, хранение и обращение. В свою очередь, международные стандарты регламентируют главным образом, документирование ПО. К ним относятся: ISO 6592:1986. ОИ. Руководство по документации для вычислительных систем; ISO 9294:1990-ТО. ИТ. Руководство по управлению документированием программного обеспечения; ISO 9127. ИТ. Пользовательская и рекламная документация на пакеты программ. Лекция 46 3.3.2. Порядок проведения сертификации Сертификация качества функционирования АИС включает: подачу заявки на сертификацию; принятие решения по заявке, в том числе выбор схемы сертификации; отбор, идентификацию образцов и их испытания; оценку производства (если это предусмотрено схемой); анализ полученных результатов и принятие решения о возможности выдачи сертификата соответствия; выдачу сертификата и лицензии на применение знака соответствия; осуществление инспекционного контроля за сертифицированной продукцией (в соответствии со схемой сертификации); проведение корректирующих мероприятий при нарушении соответствия продукции установленным требованиям и неправильном применении знака соответствия; • информацию о результатах сертификации. Сертификацию проводит аккредитованный орган по сертификации. Заявитель продукции, подлежащей сертификации, направляет в орган по сертификации заявку по форме, принятой в Системе сертификации. Орган по сертификации проводит работу по подготовке сертификации продукции по заявке. Указанная работа включает в себя: выбор схемы сертификации с учетом специфики продукции (объем, технология, требования нормативных документов и пр.) и предложений разработчика; определение количества и порядка отбора образцов, подлежащих испытаниям, если это не указано в стандартах; определение аккредитованной испытательной лаборатории, которая должна проводить испытания (если испытания не были проведены ранее); подготовку проекта договора на выполнение работ. 3.3.3. Базовые нормативные документы по обеспечению качества АИС Система функциональных показателей, оцениваемых при сертификации Согласно введенному определению качества функционирования АИС основными свойствами, определяющими качество, являются: • адекватность функционирования АИС; наличие технических возможностей АИС к взаимодействию, совершенствованию и развитию; надежность и своевременность представления информации и выполнения функциональных технологических операций; полнота, безошибочность, актуальность и конфиденциальность представляемой информации. С учетом вышеизложенного для сертификации качества функционирования АИС предлагается следующая система функциональных показателей: 1) для оценки адекватности функционирования АИС: потенциальная способность (неспособность) реализованной на предприятии системы качества по обеспечению условий для достижения требуемого качества функционирования АИС; соответствие (несоответствие) реальных функциональных возможностей ПО декларируемым в программной документации; соответствие (несоответствие) реальных функциональных возможностей аппаратных средств декларируемым в технической и эксплуатационной документации; наличие (отсутствие) закладных элементов в программном обеспечении и закладных устройств в аппаратных средствах; 2) для оценки технических возможностей АИС к взаимодей-ствию, совершенствованию и развитию: • соответствие (несоответствие) функциональным требованиям стандартов в области взаимодействия АИС, сопровождаемости ПО и его переносимости на различные вычислительные платформы в рамках жизненного цикла АИС; 3) для оценки надежности и своевременности представленияинформации и выполнения функциональных технологическихопераций: • средняя наработка на отказ программно-технических средств (ПТС) АИС; среднее время восстановления ПТС АИС после отказа; коэффициент готовности ПТС АИС; вероятность надежного представления запрашиваемой выходной информации или выполнения технологической операции; среднее время реакции АИС на запрос или на выполнение технологической операции; вероятность представления запрашиваемой информации или выполнения технологической операции за заданное время; 4) для полноты, безошибочности, актуальности и конфиденциальности представляемой информации: вероятность обеспечения полноты отражения в базе данных АИС реально существующих объектов учета предметной области; вероятность отсутствия случайных ошибок во входной информации; вероятность отсутствия случайных технологических ошибок со стороны обслуживающего персонала; вероятность отсутствия компьютерных вирусных искажений в АИС; вероятность сохранения актуальности информации в БД на момент ее использования в АИС; вероятность предотвращения несанкционированного доступа к программным и информационным ресурсам АИС; вероятность сохранения конфиденциальности выходной информации. Лекция 47 Тема: Технология групповой разработки АИС  Бизнес-аналитик В рамках командной модели MSF (MSF Team Model) бизнес#аналитик участвует в управлении продуктом. Основная задача бизнес_аналитика — разобраться в возможностях системы, относящихся к бизнесу и раскрыть их команде. Он работает с пользователями и другими заинтересованными лицами, чтобы понимать их потребности и задачи, трансформировать их в конкретные определения, сценарии и требования к качеству, которые команда разработчиков будет использовать для построения приложения. Действия и операции роли _ Действия: _ формулировка концепции проекта; _ разработка требований к качеству; _ создание сценария; _ планирование итерации. _ Операции: _ написание концепции; _ определение собирательных образов; _ уточнение собирательных образов; _ определение требований к качеству путем «мозгового штурма»; _ создание моментальных снимков деятельности; _ определение приоритетов в списке требований к качеству; _ написание требований к качеству; _ определение требований безопасности; _ работа над сценариями методом «мозгового штурма» ; _ определение приоритетов в списке сценариев; _ оценка задачи по разработке базы данных; _ выполнение ретроспективного анализа; _ оценка сценария; _ оценка требования к качеству; _ составление графика сценария; _ составление графика реализации требований к качеству; _ обзор целей. Менеджер проекта В рамках командной модели MSF менеджер проекта участвует в управлениипродуктом. Основная задача менеджера проекта — добиваться выполненияпоставленных перед командой задач в соответствии с графиком и в рамкахбюджета. На менеджере проекта лежат обязательства по планированию исоставлению графика работ, включающие разработку проекта и планов ите_раций, отслеживание состояния дел и составление отчетов, а также определению рисков и выработке мер по их уменьшению. Менеджер проекта такжепроводит консультации с бизнес_аналитиками по планированию сценари_ев и выработке требований к качеству для каждой итерации, консультирует_ся с архитекторами и разработчиками для оценки объемов работ, советует_ся с тестировщиками, чтобы спланировать тестирование, и, кроме того, со_действует взаимодействию участников команды. Человек, назначенный на этуроль, должен быть добавлен в группу доступа «Администратор проекта»(Project Administrator). Это позволит ему выполнять такие функции, как со_здание нового проекта, формирование новой команды и добавление в нее участников. Действия и операции роли _ Действия: _ контроль итерации; _ планирование итерации; _ ведение проекта. _ Операции: _ оценка задачи по разработке базы данных; _ мониторинг итерации; _ снижение риска; _ выполнение ретроспективного анализа; _ определение продолжительности итерации _ оценка сценария; _ оценка требования к качеству; _ разбиение сценариев на задачи; _ разбиение требования к качеству на задачи; _ составление графика сценария; _ составление графика реализации требований к качеству; _ оценка хода выполнения; _ оценка пороговых значений показателей тестов; _ определение риска; _ обзор целей; _ классификация дефектов. Архитектор В рамках командной модели MSF архитектор отвечает за архитектуру проекта. Его основная задача — обеспечить успех проекта путем разработкиосновных принципов приложения, которые включают в себя как организационную конфигурацию системы, так и физическую структуру ее развертывания. При этом архитектор должен стремиться к снижению сложности путем разделения системы на понятные и простые части. Архитектура приложения чрезвычайно важна, поскольку она не просто устанавливает этапыпостроения системы, а определяет, будет ли приложение обладать свойствами,присущими успешным проектам. К ним относятся: удобство использования, надежность, практичность сопровождения, производительность и безопасность, а также возможности модификации в случае изменения требований. Человек, назначенный на эту роль, должен быть добавлен в группу доступа«Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли _ Действия: _ разработка архитектуры решения; _ планирование итерации. _ Операции: _ разделение системы на подсистемы; _ определение интерфейсов; _ разработка модели угроз; _ разработка модели производительности; _ создание архитектурной модели; _ создание архитектуры инфраструктуры; _ определение требований безопасности; _ разбиение сценариев на задачи; _ разбиение требования к качеству на задачи. Разработчик В рамках командной модели MSF разработчик выполняет разработку приложения. Его основная задача — реализовать приложение согласно спецификациям и в установленные сроки. Разработчик также помогает уточнятьфизический дизайн, оценивать время и усилия для выполнения конкретныхэлементов, выполняет реализацию функций или руководит ею, подготавливает продукт к внедрению и является экспертом команды в технологических областях. Человек, назначенный на эту роль, должен быть добавлен в группудоступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли _ Действия: _ сборка продукта; _ устранение дефекта; _ реализация задачи по разработке; _ планирование итерации. _ Операции: _ разделение системы на подсистемы; _ определение интерфейсов; _ разработка модели производительности; _ запуск сборки; _ проверка выпуска; _ исправление сборки; _ приемка сборки; _ воспроизведение дефекта; _ определение причины возникновения дефекта; _ переназначение дефекта; _ выбор стратегии устранения дефекта; _ создание или изменение теста модуля; _ выполнение теста модуля; _ рефакторинг кода; _ обзор кода; _ интеграция изменений; _ оценка задачи по разработке; _ кодирование; _ анализ кода; _ оценка задачи по разработке базы данных; _ выполнение ретроспективного анализа; _ определение продолжительности итерации; _ оценка сценария; _ оценка требования к качеству; _ разбиение сценариев на задачи; _ разбиение требования к качеству на задачи; _ создание заметок о выпуске; _ развертывание продукта. Тестировщик В рамках командной модели MSF тестировщик выполняет задачи тестирования продукта. Основной задачей тестировщика является выявление проблем в продукте, которые могут неблагоприятно повлиять на его качество. Тестировщик обязан понимать контекст проекта и помогать остальным членам команды понимать решения, основанные на этом контексте. Ключевая цель тестировщика — поиск серьезных дефектов в продукте путем его тестирования и последующее их описание. Каждый найденный дефект тестировщик должен сопроводить точным описанием вредного воздействия и предложить способ обойти дефект, чтобы уменьшить это воздействие. Он должен как можно проще описать дефект и последовательность, в которой его можно воспроизвести. Тестировщик участвует в деятельности команды по определению стандартов качества продукта. Цель тестирования — убедиться, что известные функции работают правильно, и выявить возможные проблемы продукта. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Сотрудник» (Contributor). Это позволит ему выполнять все функции, необходимые в рамках его деятельности, такие как создание и изменение документов, описателей и конечных продуктов. Действия и операции роли _ Действия: _ планирование итерации; _ закрытие дефекта; _ тестирование требования к качеству; _ проверка сценария. _ Операции: _ выполнение ретроспективного анализа; _ разбиение сценариев на задачи; _ разбиение требования к качеству на задачи; _ проверка исправления; _ закрытие дефекта; _ определение подхода к тестированию _ создание теста производительности; _ создание теста безопасности; _ создание стрессового теста; _ создание нагрузочного теста; _ выбор и запуск тестового задания; _ документирование дефекта; _ оценка пороговых значений показателей тестов. Релиз-менеджер В рамках командной модели MSF релиз#менеджер отвечает за операции повыпуску продукта. Основная цель релиз_менеджера — обеспечение выпуска готового продукта. Он координирует выпуск продукта со специалистами по эксплуатации, создает план выпуска продукта и сертифицирует подготовленные к выпуску версии для поставки или развертывания. Человек, назначенный на эту роль, должен быть добавлен в группу доступа «Администратор проекта» (Project Administrator). Это позволит ему выполнять такие своифункции, как создание нового проекта, формирование новой команды и добавление в нее участников. Действия и операции роли _ Действия: _ выпуск продукта. _ Операции: _ исполнение плана выпуска; _ создание заметок о выпуске; _ развертывание продукта. Администратор баз данных Основная задача администратора баз данных в контексте разработки базыданных — поддержка создания проектов баз данных, а также внесение изменений проекта в рабочую базу данных. В дополнение к этому он долженвыполнять традиционные задачи, такие как ежедневное администрированиеи поддержка серверов баз данных. Действия и операции роли _ Действия: _ создание проекта базы данных; _ развертывание проекта базы данных. _ Операции: _ создание проекта базы данных; _ импорт существующей базы данных; _ установка параметров сборки и развертывания; _ изменение сгенерированных сценариев; _ проверка проекта базы данных; _ размещение проекта базы данных в службе управления исходным кодом; _ синхронизация проекта базы данных; _ проверка сборки; _ выполнение тестирования модулей базы данных; _ анализ изменений; _ создание резервной копии рабочей базы данных; _ установка базы данных на тестовом сервере; _ установка базы данных. Разработчик баз данных Основная задача разработчика баз данных — выполнение комплекса задач по разработке базы данных в установленные сроки. Кроме того, он отвечает за оценку стоимости, контроль над реализацией функций и помощь остальным участникам команды по вопросам, связанным с базами данных. Разработчик баз данных совместно с администратором баз данных и прикладными разработчиками участвует в итеративном жизненном цикле разработки базы данных. Действия и операции роли _ Действия: _ реализация задачи по разработке базы данных; _ планирование итерации. _ Операции: _ оценка задачи по разработке базы данных; _ обновление локальной среды проекта; _ выполнение теста модуля базы данных; _ рефакторинг базы данных; _ определение продолжительности итерации; _ оценка сценария; _ оценка требования к качеству; _ разбиение сценариев на задачи; _ разбиение требования к качеству на задачи. Лекция 48 Тема: Типы организационных структур Цели: Типы организационных структур, их характеристика Концепцию традиционных, или так называемых иерархических, организационных структур, сформулировал Макс Вебер. Согласно этой концепции структуры бывают линейными и функциональными. В линейной структуре разделение системы управления на составляющие части осуществляется по производственному признаку с учетом степени концентрации производства, технологических особенностей, широты номенклатуры продукции и других признаков. Линейная структура четко функционирует при решении задач с выполнением повторяющихся операций, но трудно приспосабливается к новым целям и задачам. Линейная структура управления широко используется мелкими и средними фирмами, осуществляющими несложное производство при отсутствии широких кооперационных связей между предприятиями (табл. 5.6). Таблица 5.6 Линейная оргструктура  Область применения функциональной структуры – это однопродуктовые предприятия; предприятия, реализующие сложные и длительные инновационные проекты; средние узкоспециализированные предприятия; научно-исследовательские и проектно-конструкторские организации; крупные специализированные предприятия (табл. 5.7). Специфические задачи менеджмента при использовании функциональной структуры: тщательный подбор специалистов-руководителей функциональных подразделений; выравнивание загрузки подразделений; обеспечение координации деятельности функциональных подразделений; разработка специальных мотивационных механизмов; Таблица 5.7 Функциональная оргструктура  предоставление автономного развития функциональных подразделений; приоритет специалистов над линейными руководителями. Современная оргструктура – это линейно-функциональная структура, которая обеспечивает разделение управленческого труда. При этом линейные звенья управления призваны командовать, а функциональные – консультировать, помогать в разработке конкретных вопросов и подготовке соответствующих решений, программ, планов. Руководители функциональных служб осуществляют влияние на производственные подразделения формально, не имея, как правило, права самостоятельно отдавать им распоряжения (табл. 5.8). Линейно-функциональная оргструктура обеспечила качественно новое разделение труда в управлении, но при решении проблемных задач становится малоэффективной. Совершенствование линейно-функциональной оргструктуры привело к появлению дивизиональной оргструктуры управления, когда отдельные подразделения, обладающие определенной самостоятельностью, вступают в договорные отношения друг с другом на основе самофинансирования. Принятие стратегических решений остается за высшим руководством. Таблица 5.8 Линейно-функциональная оргструктура  Потребность в применении дивизиональной структуры возникла в связи с резким увеличением размеров предприятий, диверсификацией их деятельности, усложнением технологических процессов. Ключевыми фигурами в управлении организациями с данной структурой становятся не руководители функциональных подразделений, а менеджеры, возглавляющие производственные подразделения. Структуризация организации по отделениям производится, как правило, по одному из критериев: по выпускаемой продукции, ориентации на потребителя, обслуживаемым регионам. Руководители вторичных функциональных служб отчитываются перед управляющим производственного подразделения. Помощники руководителя производственного отделения контролируют деятельность функциональных служб, координируя их деятельность по горизонтали (табл. 5.9). Таблица 5.9 Дивизиональная оргструктура  Область применения – это многопрофильные предприятия; предприятия с расположением в различных регионах; предприятия, осуществляющие сложные инновационные проекты. Специфические задачи менеджмента при использовании дивизиональной оргструктуры: обоснование критериев выделения проектов и продуктовых групп; тщательный подбор руководителей подразделений; обеспечение единой инновационной политики во всех продуктовых группах; предотвращение внутрифирменной конкуренции между продуктовыми группами; предотвращение автономного развития продуктовых групп; разработка специальных мотивационных механизмов, регламентирующих внутрифирменную кооперацию; приоритет линейных руководителей над специалистами. При поиске эффективной структуры управления в центре внимания всегда находились вопросы правильного соотношения централизации и децентрализации в управлении. На практике не встречается полностью централизованных или децентрализованных структур. В организациях с сильно децентрализованными структурами важнейшие решения часто принимаются только служащими, занимающими достаточно высокие должности (не ниже руководителя отдела). Такая форма децентрализации в крупных фирмах называется федеральной децентрализацией. Для определения степени централизации организации по сравнению с другими используют следующие характеристики: количество решений, принимаемых на нижестоящих уровнях управления: чем больше число решений, которые принимают нижестоящие руководители, тем меньше степень централизации; важность решений, принимаемых на нижестоящих уровнях; последствия решений, принимаемых на нижестоящих уровнях. Если руководители среднего звена могут принимать решения, затрагивающие более чем одну функцию, то организация слабо централизована; контроль за работой подчиненных. В слабо централизованной организации высшее руководство редко проверяет повседневные решения подчиненных руководителей. Оценка действий делается на основании суммарных достигнутых результатов. Лекция 49 |