Если мы исходим из предположения, что в программном обеспечении будут ошибки, то, очевидно, в первую очередь следует принять меры для их обнаружения. Более того, если необходимо принимать дополнительные меры (например, исправлять ошибки или их последствия), то все равно сначала нужно уметь обнаруживать ошибки.
Меры по обнаружению ошибок можно разбить на две подгруппы:
пассивные попытки обнаружить симптомы ошибки в процессе «обычной» работы программного обеспечения и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок.
Пассивное обнаружение ошибок
Меры по обнаружению ошибок могут быть приняты на нескольких структурных уровнях программной системы. Нас интересуют меры по обнаружению симптомов ошибок, предпринимаемые при переходе от одной компоненты к другой, а также внутри компоненты. Все это, конечно, применимо также к отдельным модулям внутри компоненты.
Разрабатывая эти меры, мы будем опираться на следующие положения:
1. Взаимное недоверие. Каждая из компонент должна предполагать, что все другие содержат ошибки. Когда она получает какие-нибудь данные от другой компоненты или из источника вне системы, она должна предполагать, что данные могут быть неправильными, и пытаться найти в них ошибки.
2. Немедленное обнаружение. Ошибки необходимо обнаружить как можно раньше. Это не только ограничивает наносимый ими ущерб, но и значительно упрощает задачу отладки.
3. Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).
Конкретные меры обнаружения сильно зависят от специфики прикладной области. Однако некоторые идеи можно почерпнуть из следующего списка:
· Проверяйте атрибуты любого элемента входных данных. Если входные данные должны быть числовыми или буквенными, проверьте это. Если число на входе должно быть положительным, проверьте его значение. Если известно, какой должна быть длина входных данных, проверьте ее.
· Применяйте «тэги» в таблицах, записях и управляющих блоках и проверяйте с их помощью допустимость входных данных. Тэг — это поле записи, явно указывающее на ее назначение.
· Проверяйте, находится ли входное значение в установленных пределах. Например, если входной элемент — адрес в основной памяти, проверяйте его
допустимость. Всегда проверяйте поле адреса или указателя на нуль и считайте, что оно неверно, если равно нулю. Если входные данные — таблица вероятностей, проверьте, находятся ли все значения между нулем и единицей.
· Проверяйте допустимость всех вариантов значений. Если входное поле — код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2,…, 9, то это обязательно код района 10.
· Если во входных данных есть какая-либо явная избыточность, воспользуйтесь ею для проверки данных.
· Там, где во входных данных нет явной избыточности, введите ее. Если ваша система использует крайне важную таблицу, подумайте о включении в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует просуммировать (по некоторому модулю) ее поля и результат поместить в специальное поле контрольной суммы. Подсистема, использующая таблицу, сможет теперь проверить, не была ли таблица случайно испорчена, — для этого только нужно выполнить контрольное суммирование.
· Сравнивайте, согласуются ли входные данные с какими-либо внутренними данными. Если на входе операционной системы возникает требование освободить некоторый блок памяти, она должна убедиться, что этот блок в данный момент действительно занят.
Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т.е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального
завершения и программные прерывания в этой компоненте и регистрирует данные об ошибке во внешнем файле.
Всегда, когда это возможно, лучше приостановить выполнение программы, чем регистрировать ошибки (либо обеспечить как дополнительную возможность работу системы в любом из этих режимов). Различие между этими методами проиллюстрируем на способах выявления причин возникающего иногда скрежета вашего автомобиля. Если автомеханик находится на заднем сиденье, то он может обследовать состояние машины в тот момент, когда скрежет возникает. Если же вы выбираете метод регистрации ошибок (записывая скрежет на магнитофон), задача диагностики будет значительно сложнее.
Пример: система PRIME
Система PRIME-это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ — central control monitor) — управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ — extended control monitor) — это реализованная микропрограммно-управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки / получения.
Защита данных — одна из основных целей системы. В этом направлении в системе PRIME сделан шаг вперед по сравнению с большинством других систем: в дополнение к обеспечению защиты в нормальных условиях ставится цель гарантировать защиту даже при наличии отдельной ошибки в программном обеспечении или отдельного сбоя аппаратуры. Меры по обнаружению ошибок составляют основу метода достижения этой цели.
Во время разработки системы PRIME были явно выделены все принимаемые операционной системой решения, ошибки в которых могут привести к тому, что данные одного пользователя станут доступными другому пользователю или его программе. Были реализованы средства обнаружения ошибок для каждого из этих решений.
Многие из них представляют собой комбинацию аппаратных и программных средств. Например, всякий раз, когда процессу пользователя выделяется терминал, ССМ запоминает идентификатор этого процесса в регистре терминала. Когда ЕСМ посылает данные на терминал, тот всегда сравнивает хранимый идентификатор с идентификатором при посланных данных. Последнее гарантирует, что отдельная ошибка в программном обеспечении или сбой аппаратуры не приведут к печати данных не на том терминале.
Система PRIME содержит механизм посылки / получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.
В качестве примера другой проверки отметим, что ССМ распределяет свободные страницы памяти между процессами пользователей и хранит список свободных страниц. Когда страница больше не нужна ЕСМ, он помечает ее и сообщает ССМ, чтобы тот включил ее в список свободных. Получая очередную выделенную страницу, ЕСМ проверяет пометку на ней, чтобы убедиться, что страница действительно свободна. Эта избыточность может быть использована для обнаружения ошибок, потому что список свободных страниц обрабатывается ССМ, а помечают страницы другие процессоры.
Активное обнаружение ошибок
Не все ошибки можно выявить пассивными методами, поскольку эти методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергаются соответствующей проверке. Можно делать и дополнительные проверки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок.
Активные средства обнаружения ошибок обычно объединяются в диагностический монитор: параллельный процесс, который периодически анализирует состояние системы с целью обнаружить ошибку. Большие программные системы, управляющие ресурсами, часто содержат ошибки, приводящие к потере ресурсов на длительное время. Например, управление памятью операционной системы сдает блоки памяти «в аренду» программам пользователей и другим частям операционной системы. Ошибка в этих самых «других частях» системы может иногда вести к неправильной работе блока управления памятью,
занимающегося возвратом сданной ранее в аренду памяти, что вызывает медленное вырождение системы.
Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некоторые идеи будут понятны из примеров. Монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри системы сообщений или операций ввода-вывода, которые необычно долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в список свободной памяти, а также различного рода странностей в файлах данных.
Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.
Пример: программа обнаружения разрушений, разработанная фирмой TRW
Система защиты ресурсов фирмы IBM — это экспериментальная модификация операционной системы OS/360 для изучения проблем, связанных с системами защиты. Используя ее, корпорация TRW разработала монитор, действующий в заранее установленные интервалы времени и пытающийся обнаружить признаки того, что программа пользователя нарушила правила защиты.
Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом
защищена. Как только обнаруживается какое-то несоответствие, немедленно выдается сообщение оператору.
Если мы исходим из предположения, что в программном обеспечении будут ошибки, то, очевидно, в первую очередь следует принять меры для их обнаружения. Более того, если необходимо принимать дополнительные меры (например, исправлять ошибки или их последствия), то все равно сначала нужно уметь обнаруживать ошибки.
Меры по обнаружению ошибок можно разбить на две подгруппы:
пассивные попытки обнаружить симптомы ошибки в процессе «обычной» работы программного обеспечения и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок.
Пассивное обнаружение ошибок
Меры по обнаружению ошибок могут быть приняты на нескольких структурных уровнях программной системы. Нас интересуют меры по обнаружению симптомов ошибок, предпринимаемые при переходе от одной компоненты к другой, а также внутри компоненты. Все это, конечно, применимо также к отдельным модулям внутри компоненты.
Разрабатывая эти меры, мы будем опираться на следующие положения:
1. Взаимное недоверие. Каждая из компонент должна предполагать, что все другие содержат ошибки. Когда она получает какие-нибудь данные от другой компоненты или из источника вне системы, она должна предполагать, что данные могут быть неправильными, и пытаться найти в них ошибки.
2. Немедленное обнаружение. Ошибки необходимо обнаружить как можно раньше. Это не только ограничивает наносимый ими ущерб, но и значительно упрощает задачу отладки.
3. Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).
Конкретные меры обнаружения сильно зависят от специфики прикладной области. Однако некоторые идеи можно почерпнуть из следующего списка:
· Проверяйте атрибуты любого элемента входных данных. Если входные данные должны быть числовыми или буквенными, проверьте это. Если число на входе должно быть положительным, проверьте его значение. Если известно, какой должна быть длина входных данных, проверьте ее.
· Применяйте «тэги» в таблицах, записях и управляющих блоках и проверяйте с их помощью допустимость входных данных. Тэг — это поле записи, явно указывающее на ее назначение.
· Проверяйте, находится ли входное значение в установленных пределах. Например, если входной элемент — адрес в основной памяти, проверяйте его
допустимость. Всегда проверяйте поле адреса или указателя на нуль и считайте, что оно неверно, если равно нулю. Если входные данные — таблица вероятностей, проверьте, находятся ли все значения между нулем и единицей.
· Проверяйте допустимость всех вариантов значений. Если входное поле — код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2,…, 9, то это обязательно код района 10.
· Если во входных данных есть какая-либо явная избыточность, воспользуйтесь ею для проверки данных.
· Там, где во входных данных нет явной избыточности, введите ее. Если ваша система использует крайне важную таблицу, подумайте о включении в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует просуммировать (по некоторому модулю) ее поля и результат поместить в специальное поле контрольной суммы. Подсистема, использующая таблицу, сможет теперь проверить, не была ли таблица случайно испорчена, — для этого только нужно выполнить контрольное суммирование.
· Сравнивайте, согласуются ли входные данные с какими-либо внутренними данными. Если на входе операционной системы возникает требование освободить некоторый блок памяти, она должна убедиться, что этот блок в данный момент действительно занят.
Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т.е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального
завершения и программные прерывания в этой компоненте и регистрирует данные об ошибке во внешнем файле.
Всегда, когда это возможно, лучше приостановить выполнение программы, чем регистрировать ошибки (либо обеспечить как дополнительную возможность работу системы в любом из этих режимов). Различие между этими методами проиллюстрируем на способах выявления причин возникающего иногда скрежета вашего автомобиля. Если автомеханик находится на заднем сиденье, то он может обследовать состояние машины в тот момент, когда скрежет возникает. Если же вы выбираете метод регистрации ошибок (записывая скрежет на магнитофон), задача диагностики будет значительно сложнее.
Пример: система PRIME
Система PRIME-это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ — central control monitor) — управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ — extended control monitor) — это реализованная микропрограммно-управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки / получения.
Защита данных — одна из основных целей системы. В этом направлении в системе PRIME сделан шаг вперед по сравнению с большинством других систем: в дополнение к обеспечению защиты в нормальных условиях ставится цель гарантировать защиту даже при наличии отдельной ошибки в программном обеспечении или отдельного сбоя аппаратуры. Меры по обнаружению ошибок составляют основу метода достижения этой цели.
Во время разработки системы PRIME были явно выделены все принимаемые операционной системой решения, ошибки в которых могут привести к тому, что данные одного пользователя станут доступными другому пользователю или его программе. Были реализованы средства обнаружения ошибок для каждого из этих решений.
Многие из них представляют собой комбинацию аппаратных и программных средств. Например, всякий раз, когда процессу пользователя выделяется терминал, ССМ запоминает идентификатор этого процесса в регистре терминала. Когда ЕСМ посылает данные на терминал, тот всегда сравнивает хранимый идентификатор с идентификатором при посланных данных. Последнее гарантирует, что отдельная ошибка в программном обеспечении или сбой аппаратуры не приведут к печати данных не на том терминале.
Система PRIME содержит механизм посылки / получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.
В качестве примера другой проверки отметим, что ССМ распределяет свободные страницы памяти между процессами пользователей и хранит список свободных страниц. Когда страница больше не нужна ЕСМ, он помечает ее и сообщает ССМ, чтобы тот включил ее в список свободных. Получая очередную выделенную страницу, ЕСМ проверяет пометку на ней, чтобы убедиться, что страница действительно свободна. Эта избыточность может быть использована для обнаружения ошибок, потому что список свободных страниц обрабатывается ССМ, а помечают страницы другие процессоры.
Активное обнаружение ошибок
Не все ошибки можно выявить пассивными методами, поскольку эти методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергаются соответствующей проверке. Можно делать и дополнительные проверки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок.
Активные средства обнаружения ошибок обычно объединяются в диагностический монитор: параллельный процесс, который периодически анализирует состояние системы с целью обнаружить ошибку. Большие программные системы, управляющие ресурсами, часто содержат ошибки, приводящие к потере ресурсов на длительное время. Например, управление памятью операционной системы сдает блоки памяти «в аренду» программам пользователей и другим частям операционной системы. Ошибка в этих самых «других частях» системы может иногда вести к неправильной работе блока управления памятью,
занимающегося возвратом сданной ранее в аренду памяти, что вызывает медленное вырождение системы.
Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некоторые идеи будут понятны из примеров. Монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри системы сообщений или операций ввода-вывода, которые необычно долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в список свободной памяти, а также различного рода странностей в файлах данных.
Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.
Пример: программа обнаружения разрушений, разработанная фирмой TRW
Система защиты ресурсов фирмы IBM — это экспериментальная модификация операционной системы OS/360 для изучения проблем, связанных с системами защиты. Используя ее, корпорация TRW разработала монитор, действующий в заранее установленные интервалы времени и пытающийся обнаружить признаки того, что программа пользователя нарушила правила защиты.
Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом
защищена. Как только обнаруживается какое-то несоответствие, немедленно выдается сообщение оператору.
1. ВЫЯВЛЕНИЯ И УСТРАНЕНИЯ Типовых НЕИСПРАВНОСТЕЙ МАТЕРИНСКОЙ ПЛАТЫ И ЕЕ КОМПОНЕНТОВ
ВЫЯВЛЕНИЯ И УСТРАНЕНИЯ ТИПОВЫХ
НЕИСПРАВНОСТЕЙ МАТЕРИНСКОЙ
ПЛАТЫ И ЕЕ КОМПОНЕНТОВ
2.
Материнская плата
Описание внешних элементов
Форм-факторы материнских плат
Признаки неисправностей материнской платы
Причины поломок
Инструменты
Разрыв печатных проводников
Обрыв конденсаторов или резисторов
Поломки внешних портов
Разрушение разъемов и слотов
Ремонт поврежденных микросхем
Проблемы с питанием платы
Перегрев компонентов
Неисправности BIOS
Как сбросить настройки BIOS
3.
4.
5. Описание внешних элементов
ОПИСАНИЕ ВНЕШНИХ ЭЛЕМЕНТОВ
1. Место под процессор
2. Вырезы под крепление
3. Разъём для подключения кулера
4. Разъём для подключения оперативной памяти
5. Разъём питания материнской платы
6. Разъёмы подключения USB
7. Перемычки для обнуления
8. Радиатор чипсета материнской платы
9. Разъёмы подключения SATA
10. Подключение питания для процессора
11. Разъём подключения монитора
12. Батарейка
13. Разъём подключения акустической системы
14. Отверстие материнской платы
15. Разъём для видеокарты
6. Форм-факторы материнской платы
Форм-фактор ATX , который был предложен еще в 1995 г. компанией Intel и с тех пор по сей день сохранил
огромную популярность. Системные платы форм фактора ATX имеют размеры 30,5 x 24,4 см. В настоящее
время большинство системных плат, корпусов и блоки питания на базе процессоров Intel и AMD выпускаются
в формате ATX.
micro ATX – уменьшенный стандарт ATX. Он используется в основном в офисных машинах, где не
требуется много слотов для наращивания конфигурации. Стандарт mATX имеет размеры 24.4 x 24.4 см и
поддерживает 4 слота расширения.
Mini-ITX — форм-фактор для материнских плат, разработанный компанией VIA Technologies. При
сохранении электрической и механической совместимости с форм-фактором ATX, материнские платы MiniITX существенно меньше по размеру (170 на 170 мм).
7.
8.
ПРИЗНАКИ НЕИСПРАВНОСТИ МАТЕРИНСКОЙ ПЛАТЫ:
ПК не реагирует на нажатие кнопки включения, либо после запуска сразу же
выключается.
Компьютер включается, но не запускается.
Необходимо прислушаться – что слышно в момент включения. Треск, писк либо щелчок
свидетельствуют о коротком замыкании на плате. Еще один признак короткого замыкания – в
момент включения может подергиваться кулер блока питания.
В таком случае при включенном ПК необходимо коснуться к южному и северному мосту.
Поломка материнской платы приводит к чрезмерному нагреву этих деталей.
Если мосты
комнатной температуры, нужно демонтировать кулер с процессора и во время включения
дотронуться до его поверхности. Если при включенном компьютере процессор остался
холодным – это говорит о поломке материнской карты.
Во время загрузки ОС либо во время работы компьютера происходит перезагрузка.
В случае такой неисправности необходимо осмотреть электролитические конденсаторы.
Вследствие перегрева поверхность конденсатора может приподниматься над поверхностью
платы. Такая деталь подлежит замене.
9. Причины поломок
ПРИЧИНЫ ПОЛОМОК
Основное разделение поломок заключается
в поломках по вине пользователя и по вине
внешних воздействий.
Пользователь может повредить порты
материнской платы при неаккуратном
обращении,
повредить
дорожки
на
плате(например отвёрткой) или же просто
забыть какую-то вещь (скрепку, шуруп и
т.п.) внутри, что может стать причиной
короткого замыкания.
Внешние повреждения могут возникать по
причине банального перегрева, проблем с
питанием и некачественных деталей. Так
же
проблемы
могут
быть
вызваны
ошибками при проектировании самой
материнской платы.
10. Инструменты
ИНСТРУМЕНТЫ
Если вы предоставляете сервисные услуги
по ремонту ПК или же пытаетесь починить
материнскую плату самостоятельно, вам
желательно иметь под рукой следующие
инструменты:
Паяльная жидкость и припой;
Паяльник
обычный,
желательно
мощностью не более 40 Ватт и
работающий от низкого напряжения,
через трансформатор;
Паяльник газовый, либо монтажный фен;
Скальпель, ножницы, спирт;
Мультиметр;
Индикатор POST кодов или тестовый
BIOS.
11. Разрыв печатных проводников
РАЗРЫВ ПЕЧАТНЫХ ПРОВОДНИКОВ
Пользователь при разборке или чистке ПК может
повредить дорожки на материнской плате. Если с
повреждениями на внешних слоях платы(платы
обычно делают в 5-6 слоёв) ещё можно справится, то
с внутренними повреждениями уже ничего нельзя
сделать.
Производители материнских плат знают о том что
поломки такого вида далеко не редкость и
стараются располагать элементы подальше от
дорожек.
12. Ремонт разрыва печатных проводников
РЕМОНТ РАЗРЫВА ПЕЧАТНЫХ ПРОВОДНИКОВ
Данную ситуацию можно исправить, если на плате повреждены внешние дорожки. При внутреннем обрыве
проводников материнскую плату можно оставить на запасные детали, поскольку работать она больше уже никогда не
будет.
Исправить внешний обрыв просто. Для восстановления дорожек проще всего использовать медные волоски из
обычных низковольтных проводов.
Для этого следует снять лак с восстанавливаемых каналов примерно на 1 мм, после чего залудить дорожки и медные
волоски и аккуратно припаять их к местам разрывов. Подготовьте тонкий медный провод и скальпель. Зачистите сам
провод и оба конца оборванного проводника скальпелем. Затем нанесите паяльную жидкость или канифоль, пинцетом
приложите подготовленный проводок к проводнику и быстрым точечным нагревом припаяйте его с двух сторон.
После этого необходимо протереть спиртом воссозданный участок и убрать скальпелем остатки припоя, которые
могут замыкать на соседние проводники.
13. Ремонт разрыва печатных проводников
РЕМОНТ РАЗРЫВА ПЕЧАТНЫХ ПРОВОДНИКОВ
Возможные варианты поломок:
Были порезаны дорожки и деформированы ножки чипа
При таком повреждении ни в коем случае нельзя
стараться вернуть ножки в исходное положение!
Это закончится тем, что они отвалятся совсем, и
придется
менять
микросхему.
Нужно с помощью увеличительного стекла и скальпеля
поправить ножки ровно настолько, чтобы ликвидировать
между ними замыкания, и осторожно припаять
оторвавшиеся от печатной платы обратно.
Были также повреждены немаркированные чипы
Это
самая
сложная
ситуация.
В этом случае придется искать точно такую же
материнскую плату и определять разновидность
поврежденного элемента, либо искать точно такую же
сгоревшую плату и снимать элемент с нее.
14. Обрыв конденсаторов или резисторов
ОБРЫВ КОНДЕНСАТОРОВ ИЛИ РЕЗИСТОРОВ
На материнской плате содержится большое количество миниатюрных
конденсаторов и резисторов. Их очень легко отломать, орудуя отверткой
или
неаккуратно
вставляя
платы
расширения.
Кроме
того,
электролитические конденсаторы более крупного размера также
подвержены механическому повреждению.
15. Ремонт обрыва конденсаторов или резисторов
РЕМОНТ ОБРЫВА КОНДЕНСАТОРОВ ИЛИ РЕЗИСТОРОВ
Чтобы исправить такое повреждение, нужно иметь аналогичные по параметрам
резисторы и конденсаторы. Однако беда в том, что многие производители просто не
маркируют такие детали, так как они слишком малы. После того как вы нашли
необходимые детали, подготовьте место пайки. Обычно деталь отрывается не
полностью, поэтому прежде всего следует отпаять ее остатки.
Удерживая пинцетом деталь, точным коротким нагревом припаяйте ее с двух
сторон. После этого опять очистите место пайки, чтобы избежать короткого
замыкания.
16. Поломки ВНЕШНИХ портов
ПОЛОМКИ ВНЕШНИХ ПОРТОВ
Возникает чаще всего на компьютерах, к которым часто или
неосторожно подключают и отключают периферию. Ресурс у
портов далеко не бесконечный. Иногда контакты могут немного
отходить от порта или же порты могут расшататься настолько, что
штекеры просто не будут держаться в них.
17. Ремонт внешних портов
РЕМОНТ ВНЕШНИХ ПОРТОВ
Поменять разъем на плате не так сложно, но конечно есть свои правила.
Во-первых, нужно найти такой же разъем.
Во-вторых, снять его, не повредив
В-третьих, снять неисправный разъем, не испортив печатную плату, и установить на его
место новый.
*Выпаять разъем обычным паяльником, не повредив печатную плату или сам разъем,
практически невозможно. Подобное можно осуществить только с газовым паяльником,
либо с монтажным феном.
После извлечения целого разъема, предназначенного для пересадки, с ножек разъема
следует снять припой и выровнять их пинцетом.
Демонтировав неисправный разъем, нужно почистить место пайки спиртом и с
помощью обычного паяльника и иголки восстановить залитые припоем отверстия на
месте контактов.
После этого, предварительно нанеся на место пайки паяльную жидкость, можно
просто вставить новый разъем на место старого и путем прогрева все тем же газовым
паяльником припаять его обратно.
18. Разрушение разъемов и слотов
РАЗРУШЕНИЕ РАЗЪЕМОВ И СЛОТОВ
Разрушить любой разъем на материнской плате крайне легко. Для этого
достаточно сильно нажать на него или вставлять и вытягивать кабель не равномерно,
а под углом. Несмотря на свои не слишком малые размеры, слоты расширения
также подвержены поломке. Так, если плата расширения, например видеокарта,
имеет нестандартный размер, а материнская плата прикручена слишком близко к
задней стенке системного блока, то для установки этой платы расширения придется
приложить достаточную силу, что при внезапном перекосе или неаккуратном
движением может повредить слот. Ремонт: невозможен.
19. Ремонт ПОВРЕЖДЕННЫХ МИКРОСХЕМ
РЕМОНТ ПОВРЕЖДЕННЫХ МИКРОСХЕМ
Одним из возможных побочных эффектов соскальзывания отвертки может стать
повреждение одного из многочисленных выводов микросхем материнской платы. Если
микросхема имеет множество выводов, что требует их плотного размещения, то
некоторые из них могут прижаться друг к другу, что приведет к возникновению короткого
замыкания и, возможно, выходу микросхемы из строя.
20.
РЕМОНТ ПОВРЕЖДЕННЫХ МИКРОСХЕМ
Это довольно сложная ситуация, поскольку выводы таких
микросхем чаще всего очень тонкие. При попытке выровнять
поврежденные выводы половина из них наверняка оторвется,
после чего придется заменить всю микросхему, что в домашних
условиях практически невозможно.
Поскольку исправлять поломку все равно нужно, то
единственное, что можно сделать, – скальпелем и пинцетом
попытаться хоть немного отодвинуть поврежденные ножки друг
от друга. Делать это нужно очень осторожно, так как слишком
сильный нажим может окончательно повредить микросхему.
Если при деформации некоторые ножки оторвались от
печатных проводников, то их нужно припаять на свои места.
После этого обязательно аккуратно почистите место пайки,
поскольку если этого не сделать, то между ножками микросхемы
может возникнуть короткое замыкание.
21. Проблемы с питанием платы
ПРОБЛЕМЫ С ПИТАНИЕМ ПЛАТЫ
Подобные проблемы могут возникать из-за некачественных блоков питания или
перебоев питания. Для предотвращения подобного лучше всего выбирать
качественные блоки питания и пользоваться источниками бесперебойного
питания.
Если
поломка
всё-таки
возникла:
Нужно проверить наличие и соответствие норме напряжений на процессоре,
оперативной
памяти
и
шине
PCI.
Но перед этой трудоемкой процедурой стоит провести предварительный
анализ ситуации с помощью индикатора POST кодов — он укажет на явно
неисправные
узлы.
Протестировав плату и определив по указанному коду неисправный участок,
можно приступать к более детальной диагностике и ремонту.
Неисправности в цепи питания материнской платы могут возникать также по
вине
производителя.
Чаще всего это выражается в стремительно высыхающих электролитических
конденсаторах (причины могут быть очень разные: от низкого качества
конденсаторов до перегрева), которые при этом теряют свою емкость и могут
вызвать
короткое
замыкание.
Чаще всего в результате этого внешний вид элементов схемы не меняется, но
плата не работает.
22. Перегрев компонентов
ПЕРЕГРЕВ КОМПОНЕНТОВ
Этот факт также довольно часто имеет место. В
большей
степени
подвержены
перегреву
материнские
компонентов
платы,
которые
оборудованы пассивными системами охлаждения с
недостаточной площадью рассеивания тепла. При
разгоне (то есть при ручном увеличении скорости
работы) такая система охлаждения не справляется с
поставленной перед ней задачей, что приводит к
повышенному
невозможен.
нагреву
компонентов.
Ремонт:
23. Неисправности BIOS
НЕИСПРАВНОСТИ BIOS
Иногда случается так, что ПК перестаёт запускаться, причиной
тому может стать BIOS. Ситуации могут быть совершенно
разные, основными же являются:
1.
«Кривая» прошивка BIOS
2.
Сбой во время перепрошивки, например скачок напряжения
3.
Разгон частот процессорашин
4.
Вирусы
В платах GIGABYTE может быть установлено 2 платы с
BIOS(перезаписываемая не перезаписываемая). Благодаря такой
системе, при сбое перезаписываемой, управление на себя берёт
вторая.
В некоторых видах материнских плат поддерживается
Recovery Mode. Этот режим либо запускается автоматически при
порче микропрограммы, либо устанавливается специальным
джампером на плате.
24. КАК СБРОСИТЬ НАСТРОЙКИ BIOS
Обнулять конфигурацию BIOS необходимо в следующих случаях:
Если
необходимо сбросить пароль на вход в БИОС (или пароль на продолжение запуска
Если
компьютер работает не стабильно;
Если
компьютер не загружает операционную систему;
ОС);
Если
Вы изменили конфигурацию настроек BIOS Setup, но не уверены в правильности
выполнения своих действий.
Сброс настроек БИОС заключается в обнулении содержимого памяти CMOS
(разрушение контрольной суммы CMOS) до стандартных значений (заводских настроек).
25.
Способ № 1. Сброс настроек BIOS Setup с помощью перемычки CLRTC на
материнской плате.
Перемычка располагается на системной плате рядом с батарейкой, питающей CMOS-память.
Она по умолчанию стоит в положении 1-2.
Для обнуления BIOS Setup необходимо переставить перемычку в положение 2-3 примерно на 15 секунд.
Операцию необходимо выполнять при полностью отключенном компьютере (необходимо вынуть даже
розетку из электросети).
В материнских платах премиум класса для выполнения данной операции зачастую имеется
специальная кнопка (CLR CMOS).
26.
Способ № 2. Вынимаем батарейку.
Выключаем компьютер. Снимаем крышку системного блока
и ищем на материнской плате батарейку, которая питает
CMOS-память. Аккуратно извлекаем батарейку из гнезда и
спустя некоторое время (минут 10-15) устанавливаем ее
обратно. Заводские настройки должны установиться.
Способ № 3. С помощью опций BIOS Setup.
Если у Вас имеется возможность зайти в BIOS Setup, то
установить заводские настройки можно с помощью
пункта Load Defaults BIOS (название может быть другое:
Load BIOS Setup Defaults, Load Safe-Fail Defaults…).
27. СПИСОК ЛИТЕРАТУРЫ
1. Ватаманюк А. Устранение неполадок ПК.- СПб.: Питер, 2010.- 272 с.
2. Гаряев П.В. Техническое обслуживание средств вычислительной техники. Учебнометодическое пособие. Пермь, 2012.
3. Логинов М.Д. Техническое обслуживание средств вычислительной
техники: учебное пособие. – М.: Бином. Лаборатория знаний, 2011.
4. Мюллер С. Модернизация и ремонт ПК, 18-е издание.: Пер. с англ.
– М.: ООО «И.Д. Вильямс», 2012.
5. Бигелоу Стивен. Устройство и ремонт персонального компьютера. Аппаратная
платформа и основные компоненты, пер. с англ. — М.: ООО «Бином-Пресс», 2013-967 с.
6. Содержание
Подборка по базе: Темы лекций для конспектирования ТЭО 21.docx, 2.5 лекции.docx, МФЮА. Лекции по УОДБ.docx, конспект лекции по хирургической стоматологии.rtf, философия лекции.docx, Презентация к лекции — Методы физического воспитания.pptx, Презентация к лекции-Воспитание_выносливости.pptx, Тест по лекции 8.docx, Готовые задачи по специальности _Бухгалтерский учет и аудит_ 202, Товароведение лекции.docx
Тема 3.4 Тестирование отдельных модулей
Инструментарии анализа качества программных продуктов в среде разработки.
Software Quality Assurance (SQA) — это комплекс мероприятий по обеспечению качества в процессах разработки программного обеспечения. Это гарантирует, что разработанное программное обеспечение соответствует и соответствует определенным или стандартизированным спецификациям качества. SQA — это непрерывный процесс в рамках жизненного цикла разработки программного обеспечения (SDLC), который регулярно проверяет разработанное программное обеспечение, чтобы убедиться, что оно соответствует требуемым показателям качества.
Практики SQA применяются в большинстве типов разработки программного обеспечения независимо от используемой модели разработки программного обеспечения. SQA включает и внедряет методологии тестирования программного обеспечения для тестирования программного обеспечения. Вместо проверки качества после завершения, SQA обрабатывает тест на качество на каждом этапе разработки, пока программное обеспечение не будет завершено. С SQA процесс разработки программного обеспечения переходит в следующую фазу только тогда, когда текущая / предыдущая фаза соответствует требуемым стандартам качества. SQA обычно работает над одним или несколькими отраслевыми стандартами, которые помогают в разработке рекомендаций по качеству программного обеспечения и стратегий реализации.
Включает в себя следующие виды деятельности:
- Определение и реализация процесса
- Аудиторская проверка
- Повышение квалификации
Могут проводиться процессы:
- Методология разработки программного обеспечения
- Управление проектом
- Управление конфигурацией
- Разработка требований / Управление
- Предварительный расчет
- Разработка программного обеспечения
- Тестирование и др.
После того, как процессы определены и внедрены, Контроль качества выполняет следующие обязанности:
- Выявить слабые места в процессах
- Исправить эти недостатки, чтобы постоянно улучшать процесс
Выявление ошибок системных компонентов.
Одной из основных причин изменений комплексов программ являются организационные дефекты при модификации и расширении функций ПС, которые отличаются от остальных типов и условно могут быть выделены как самостоятельные. Ошибки и дефекты данного типа появляются из-за недостаточного понимания коллективом специалистов технологии процесса ЖЦ ПС, а также вследствие отсутствия четкой его организации и поэтапного контроля качества продуктов и изменений.
Изменения характеристик системы и внешней среды, принятые в процессе разработки ПС за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных характеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок, и дефектов развития проекта. Ситуация с такими ошибками дополнительно усложняется тем, что эксперименты по проверке взаимодействия ПС с реальной внешней средой во всей области изменения параметров зачастую сложны и дороги, а в отдельных случаях, при создании опасных ситуаций, недопустимы.
Сложность проявления, обнаружения и устранения ошибок значительно конкретизируется и становится измеримой, когда устанавливается связь этого понятия с конкретными ресурсами, необходимыми для решения соответствующей задачи, и возможными проявлениями дефектов. При разработке и сопровождении программ основным лимитирующим ресурсом обычно являются допустимые трудозатраты специалистов, а также ограничения на сроки разработки, параметры ЭВМ, технологию проектирования корректировок ПС. Показатели сложности при анализе можно разделить на две большие группы:
- сложность ошибок при создании корректировок компонентов и комплекса программ — статическая сложность, когда реализуются его требуемые функции, вносятся основные дефекты и ошибки;
- сложность проявления ошибок функционирования программ и получения результатов — динамическая сложность, когда проявляются дефекты и ошибки, отражающиеся на функциональном назначении, рисках и качестве применения версии ПС.
Системные ошибки в ПС определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Кроме того, эти процессы зачастую зависят от самих алгоритмов и поэтому не могут быть достаточно определены и описаны заранее без исследования изменений функционирования ПС во взаимодействии с внешней средой. На начальных этапах не всегда удается точно и полно сформулировать целевую задачу всей системы, а также целевые задачи основных групп программ, и эти задачи уточняются в процессе проектирования. В соответствии с этим уточняются и конкретизируются спецификации на отдельные компоненты и выявляются отклонения от уточненного задания, которые могут квалифицироваться как системные ошибки.
Характеристики внешних объектов, принятые в качестве исходных данных в процессе разработки алгоритмов, могут являться результатом аналитических расчетов, моделирования или исследования аналогичных систем. Во всех случаях может отсутствовать полная адекватность условий получения предполагаемых и реальных характеристик внешней среды, что является причиной сложных и трудно обнаруживаемых ошибок. Это усугубляется тем, что очень часто невозможно заранее предусмотреть все разнообразие возможных внешних условий и реальных сценариев функционирования и применения версий программного продукта.
При автономной и в начале комплексной отладки версий ПС относительная доля системных ошибок может быть невелика (около 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки новых базовых версий ПС.
Методы идентификации сбоев и ошибок
Ошибка (error) — состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.
Дефект (fault) в программе — следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой.
Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования.
Отказ может быть результатом следующих причин:
- ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;
- спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;
- проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);
- программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован не полностью.
Таким образом, отказы, как правило, являются результатами одной или более ошибок в программе, а также наличия разного рода дефектов.
Все ошибки, которые возникают в программах, принято подразделять на следующие классы:
- логические и функциональные ошибки;
- ошибки вычислений и времени выполнения;
- ошибки ввода/вывода и манипулирования данными;
- ошибки интерфейсов;
- ошибки объема данных и др.
Логические ошибки являются причиной нарушения логики алгоритма, внутренней несогласованности переменных и операторов, а также правил программирования. Функциональные ошибки — следствие неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации и т.д. Ошибки вычислений возникают по причине неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов. Ошибки времени выполнения связаны с необеспечением требуемой скорости обработки запросов или времени восстановления программы. Ошибки ввода-вывода и манипулирования данными являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее. Ошибки интерфейса относятся к ошибкам взаимосвязи отдельных элементов друг с другом, что проявляется при передаче данных между ними, а также при взаимодействии со средой функционирования. Ошибки объема относятся к данным и являются следствием того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки.
Анализ типов ошибок в программах является необходимым условием создания планов тестирования и методов тестирования для обеспечения правильности ПО.
Автоматизация тестирования в продуктивной среде
Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде.
Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:
- Быстрое получение обратной связи
- Аккуратное и тщательное тестирование
- Высокое покрытие тестами
- Быстрое обнаружение ошибок
- Повторное использование тестов
- Более короткие сроки поставки
- Адаптация для DevOps
- Экономия времени и денег
Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле.
Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.
Пользовательский опыт (UX) — Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.
Стадии ранней разработки — Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии.
Функциональность, не имеющая большой важности — Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную.
Тесты без понятных результатов — Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом.
Тема 3.5 Реинжиниринг бизнес-процессов в информационных системах
Сущность реинжиниринга бизнес-процессов. Этапы реинжиниринга
Инжиниринг бизнеса — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями.
Реинжиниринг — это фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы (термин «реинжиниринг» ввел М. Хаммер).
Это определение содержит четыре ключевых слова: «фундаментальный», «радикальный», «резкий (скачкообразный)» и «процесс» (наиболее важное слово).
1. Фундаментальный. На начальной стадии реинжиниринга необходимо ответить на такие основные вопросы:
- почему компания делает то, что она делает?
- почему компания делает это таким способом?
- какой хочет стать компания?
Отвечая на эти вопросы, специалисты должны переосмыслить текущие правила и положения (зачастую не сформулированные в письменной форме) ведения бизнеса и часто оказывающиеся устаревшими, ошибочными или неуместными.
2. Радикальный. Радикальное перепроектирование — это изменение всей существующей системы, а не только поверхностные преобразования, т.е. входе радикального перепроектирования предлагаются совершенно новые способы выполнения работы.
3. Резкий (скачкообразный). Реинжиниринг не применяется в тех случаях, когда необходимо улучшение либо увеличение показателей деятельности компании на 10-100%, а используются более традиционные методы (от произнесения зажигательных речей перед сотрудниками до проведения программ повышения качества), применение которых не сопряжено со значительным риском. Реинжиниринг целесообразен только в тех случаях, когда требуется достичь резкого (скачкообразного) улучшения показателей деятельности компании (500-1000% и более) путем замены старых методов управлении новыми.
Смысл реинжиниринга бизнес-процессов в двух его основных этапах:
- определение оптимального (идеального) вида бизнес-процесса (в первую очередь основного);
- определение наилучшего (по средствам, времени, ресурсам и т. п.) способа перевода существующего бизнес-процесса в оптимальный.
Порядок проведения:
- Разработка корпоративной стратегии;
- Определение ключевых компетенций, которые необходимы для внедрения стратегии;
- Подробный анализ существующих процессов;
- Выявление процессов, требующих изменения;
- Определение ключевых показателей эффективности для бизнес-процессов;
- Собственно реинжиниринг;
- Контроль и постоянное совершенствование новых процессов на основе ключевых показателей эффективности.
Изучение методологии структурного системного анализа
Методология структурного анализа и проектирования ПО определяет шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. В настоящее время успешно используются такие методологии, как SADT (Structure Analysis and Design Technique), структурный системный анализ Гейна-Сарсона, структурный анализ и проектирование Йодана/Де Марко, развитие систем Джексона и другие.
Перечисленные структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций и отражают подход к разработке ПО с позиций рецептов «кулинарной книги».
Несмотря на достаточно широкий спектр используемых методов и диаграммных техник, большинство методологий базируется на следующей «классической» совокупности:
Диаграммы потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем;
Расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах решений, картах и схемах потоков управления;
Диаграммы «сущность-связь» (в нотации Чена или Баркера) для проектирования структур данных, схем БД, форматов файлов как части всего проекта;
Структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры модулей.
Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данных раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных.
Основные методологии обследования организаций
Понятие «моделирование бизнес-процессов» пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании.
Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящий момент к семейству IDEF можно отнести следующие стандарты:
IDEF0 — методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets);
IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.
Презентация на тему: » Диагностика неисправностей РС Диагностика по сообщениям BIOS Диагностические программы.» — Транскрипт:
1
Диагностика неисправностей РС Диагностика по сообщениям BIOS Диагностические программы
2
Проблемы при включении Не светятся индикаторы Нет изображения на мониторе Слышен шум из системного блока Слышны звуковые сигналы Система не загружается
3
Диагностика по сообщениям BIOS Звуковые сигналы POST Экранные сообщения POST
4
Как определить марку BIOS? ПК с разными BIOS имеют различную кодировку сигналов. При загрузке компьютера первое что появляется на экране — название BIOS. Если вы не успеваете посмотреть, зайдите в CMOS SETUP с помощью клавиши DEL. Марка BIOS пишется вверху. Либо искать микросхему BIOS на материнской плате.
5
Звуковые сигналы POST
6
7
8
Экранные сообщения POST AMI BIOS – «CMOS Battery State Low», «CMOS Checksum Failure», «CMOS Memory Size Mismatch», «CMOS System Optons Not Set», «CMOS Time and Date Not Set»- необходимо запустить SETUP или заменить батарейку – «Keyboard Error», «K/B Interface Error», «8042 Gate-A20 Error!»- проблемы с клавиатурой-переподключить клавиатуру, если не исчезает, то неисправность MB – «FDD Controller Failure», «HDD Controller Failure»-ошибки могут быть вызваны нарушением контакта в соединителях устройств – «C: Drive Error», «C: Drive Failure»-неверно установлен тип диска в SETUP, неисправность HDD
9
Экранные сообщения POST AMI BIOS «Diskette Boot Failure», «Invalid Boot Diskette»-не читается или не системная дискета Memory Parity Error at XXXX-неисправность памяти
10
Экранные сообщения POST Award BIOS – «CMOS BATTERY HAS FAILED», «CMOS CHECKSUM ERROR», необходимо заменить батарейку, запустить SETUP – «KEYBOARD ERROR OR NO KEYBOARD PRESENT»- проблемы с клавиатурой или не подключена клавиатура – «ERROR ENCOUNTERED INITIALIZING HARD DRIVE», «ERROR INITIALIZING HARD DRIVE CONTROLLER»-ошибки могут быть вызваны нарушением контакта в соединителях диска или неверной установкой перемычек, кабелей – « MEMORY PARITY ERROR AT XXXX», «MEMORY ADDRESS ERROR AT XXXX»-неисправность памяти
11
Диагностические программы – Сбор данных о системе – Измерение производительности – Диагностика неисправности – Встроенные средства Windows