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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


реферат Методология и технология проектирования ЛИС

Информация:

Тип работы: реферат. Добавлен: 07.10.2012. Сдан: 2012. Страниц: 8. Уникальность по antiplagiat.ru: < 30%

Описание (план):


?Методология и технология проектирования ЛИС
Современные методологии и реализующие их технологии проектирования АИС поставляются в электронном виде вместе с CASE-средствами (рассмотрены далее) и включают библиоте­ки процессов, шаблонов, методов, моделей и других компонен­тов, предназначенных для построения ПО того класса систем, на который ориентирована методология. Электронные методо­логии и технологии составляют ядро комплекса согласованных инструментальных средств разработки АИС [6, 8, 16—18]. Осо­бенности современных методологических решений проектиро­вания АИС невозможно реализовать без определенных техноло­гий проектирования, соответствующих масштабу и специфике проекта.
Технология проектирования АИС — это совокупность методов и средств проектирования АИС, а также методов и средств орга­низации проектирования (управление процессом создания и модернизации проекта АИС) [8, 16—18]. В основе технологии про­ектирования лежит технологический процесс (ТП), который оп­ределяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.
Согласно [20] ТП проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и со­подчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектирова­нии АИС, могут быть определены как неделимые технологиче­ские операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными, которые вырабатывают по установленным критери­ям оценки результатов проектирования.
Таким образом, технология проектирования задается регла­ментированной последовательностью технологических опера­ций, выполняемых в процессе создания проекта на основе того или иного метода.
Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС.
Основные требования, предъявляемые к выбираемой техно­логии проектирования, следующие:
•   созданный с помощью этой технологии проект должен от­вечать требованиям заказчика;
•   технология должна максимально отражать все этапы цикла жизни проекта;
•   технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;
•   технология должна способствовать росту производительно­сти труда проектировщиков;
•   технология должна обеспечивать надежность процесса про­ектирования и эксплуатации проекта;
•   технология должна способствовать простому ведению про­ектной документации.
Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология про­ектирования предполагает наличие некоторой концепции, прин­ципов проектирования и реализуется набором методов и средств.
Методы проектирования АИС можно классифицировать по степени использования средств автоматизации, типовых проект­ных решений, адаптивности к предполагаемым изменениям.
По степени автоматизации различают:
•   ручное проектирование, при котором проектирование ком­понентов АИС осуществляется без использования специ­альных инструментальных программных средств; програм­мирование производится на алгоритмических языках;
•   компьютерное проектирование, при котором генерация или конфигурация (настройка) проектных решений произ­водится с использованием специальных инструментальных
программных средств.
 
По степени использования типовых проектных решений разли­чают:
•   оригинальное   (индивидуальное)   проектирование,   когда проектные решения разрабатываются «с нуля» в соответст­вии с требованиями к АИС;
•   типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программ­ных модулей).
Оригинальное проектирование АИС предполагает максималь­ный учет особенностей автоматизированного объекта.
Типовое проектирование выполняется на основе готовых ре­шений и является обобщением опыта, полученного ранее при создании родственных проектов.
По степени адаптивности проектных решений различаются следующие методы:
•   реконструкция — адаптация проектных решений выполня­ется  путем  переработки  соответствующих компонентов (перепрограммирования программных модулей);
•   параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;
•   реструктуризация модели — изменяется модель предметной области, что приводит к автоматическому переформирова­нию проектных решений.
Сочетание различных признаков классификации методов проектирования обусловливает характер используемой техноло­гии проектирования АИС. Выделяются два основных класса технологии проектирования: каноническая и индустриальная (табл. 1.5). Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметриче­ски-ориентированное или модельно-ориентированное) проекти­рование. Использование индустриальных технологий проекти­рования не исключает использования в отдельных случаях канонической технологии [18, 19].

Каноническое проектирование АИС ориентировано на исполь­зование главным образом каскадной модели жизненного цикла АИС. Стадии и этапы работы такого проектирования описаны в ГОСТ 34.601-90.
В зависимости от сложности объекта автоматизации и набо­ра задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоемкость. До­пускается объединять последовательные этапы и исключать не­которые из них на любой стадии проекта. Допускается также на­чинать выполнение работ следующей стадии до окончания пре­дыдущей.
Стадии и этапы создания АИС, выполняемые организация­ми-участниками, прописываются в договорах и технических за­даниях на выполнение работ.
Стадия 1. Формирование требований к АИС:
•    обследование объекта и обоснование необходимости созда­ния АИС;
•    формирование требований пользователей к АИС;
•    оформление отчета о выполненной работе и тактико-тех­нического задания на разработку.
Стадия 2. Разработка концепции АИС:
•              изучение объекта автоматизации;
• проведение необходимых научно-исследовательских работ; . разработка вариантов концепции АИС, удовлетворяющих требованиям пользователей;
•              оформление отчета и утверждение концепции.
Стадия 3. Техническое задание:
. разработка и утверждение технического задания на созда­ние АИС.
Стадия 4. Эскизный проект:
. разработка предварительных проектных решений по систе­ме и ее частям;
. разработка эскизной документации на АИС и ее части.
Стадия 5. Технический проект:
. разработка проектных решений по системе и ее частям;
•              разработка документации на АИС и ее части;
. разработка и оформление документации на поставку ком­плектующих изделий;
. разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация:
•              разработка рабочей документации на АИС и ее части;
• разработка и адаптация программ.
Стадия 7. Ввод в действие:
•   подготовка объекта автоматизации;
•   подготовка персонала;
• комплектация АИС поставляемыми изделиями (программ­ными и техническими средствами, программно-технически­ми комплексами, информационными изделиями);
• строительно-монтажные работы;
•              пусконаладочные работы;
• проведение предварительных испытаний;
•   проведение опытной эксплуатации;
•   проведение приемочных испытаний.
Стадия 8. Сопровождение АИС:
• выполнение работ в соответствии с гарантийными обяза­тельствами;
•              послегарантийное обслуживание.
Рассмотрим  специфику составляющих некоторых стадий подробнее.
Обследование — это изучение и анализ организационной структуры предприятия, его деятельности и существующей сис­темы обработки информации [20]. Материалы, полученные в ре­зультате обследования, используются для:
•    обоснования разработки и поэтапного внедрения систем;
•    составления технического задания на разработку систем;
•    разработки технического и рабочего проектов систем.
На этапе обследования целесообразно выделить две состав­ляющие: определение стратегии внедрения АИС и детальный анализ деятельности организации.
Основная задача первого этапа обследования — оценка ре­ального объема проекта, его целей и задач на основе выявлен­ных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком АИС самостоятельно, или с привлечением кон­салтинговых организаций. Этап предполагает тесное взаимодей­ствие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия — полу­чить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в ре­зультате интервью, бесед или семинаров с руководством, экспер­тами и пользователями.
По завершении стадии обследования появляется возмож­ность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (на аппаратное обеспечение, на закупаемое программное обеспечение и на раз­работку нового программного обеспечения).
Результатом этапа определения стратегии является документ (технико-экономическое обоснование — ТЭО — проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (гра­фик выполнения работ) и сколько это будет стоить (для крупных проектов — это график финансирования на разных этапах ра­бот). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидае­мый экономический эффект (если его удается оценить).
Примерное содержание ТЭО:
•    ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
•    совокупность условий, при которых предполагается экс­плуатировать будущую систему, — архитектура системы, аппаратные и программные ресурсы, условия функционирова­ния, обслуживающий персонал и пользователи системы;
•   сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
•   описание выполняемых системой функций;
•   возможности развития и модернизации системы;
•   интерфейсы и распределение функций между человеком и системой;
•   требования к ПО и системам управления базами данных (СУБД).
На этапе детального анализа деятельности организации изу­чаются деятельность, обеспечивающая реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчинен­ности вышестоящим органам управления. Здесь следует наметить инструктивно-методические и директивные материалы, на осно­вании которых определяются состав подсистем и перечень задач, а также возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаи­мосвязанных формах:
•   функции — информация о событиях и процессах, которые
происходят в автоматизируемой организации;
•   сущности — информация о классах объектов, имеющих значение для организации и о которых собираются данные.
При изучении каждой функциональной задачи управления определяются:
•    наименование задачи; сроки и периодичность ее решения;
•    степень формализуемости задачи;
•    источники информации, необходимые для решения задачи;
. показатели и их количественные характеристики;
•    порядок корректировки информации;
 
•   действующие алгоритмы расчета показателей и возможные методы контроля;
•   действующие средства сбора, передачи и обработки инфор­мации;
•   действующие средства связи;
•   принятая точность решения задачи;
•   трудоемкость решения задачи;
•   действующие формы представления исходных данных и ре­зультатов их обработки в виде документов;
•   потребители результатной информации по задаче.
 
Одной из наиболее трудоемких, хотя и хорошо формализуе­мых, задач этого этапа является описание документооборота ор­ганизации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:
•   количество документов;
•   место формирования показателей документов;
•   взаимосвязь документов при их формировании;
•   маршрут и длительность движения документа;
•   место использования и хранения данного документа;
•   внутренние и внешние информационные связи;
•   объем документа в знаках.
По результатам обследования устанавливают перечень задач управления, подлежащих автоматизации, и очередность их раз­работки.
На этапе обследования следует классифицировать планируе­мые функции системы по степени важности. Один из возможных форматов представления такой классификации — MuSCoW [22]. Эта аббревиатура расшифровывается так: Must have — необходи­мые функции; Should have — желательные функции; Could have — возможные функции; Won't have — отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной работы системы возможности. Реализация функций второй и третьей категорий ограничивается временными и фи­нансовыми рамками: разрабатывается необходимое, а также мак­симально возможное в порядке приоритета число функций вто­рой и третьей категорий. Последняя категория функций особен­но важна, поскольку нужно четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах [6, 16, 18]:
•   модель «как есть» («as is») — отражает существующие в ор­ганизации бизнес-процессы;
•   модель «как должно быть» («to be») — отражает необходи­мые изменения бизнес-процессов с учетом внедрения АИС.
Уже на этапе анализа необходимо привлекать к работе груп­пы тестирования для решения следующих задач:
•              получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных сис­тем, СУБД и т. п.;
• разработки плана работ по обеспечению надежности АИС и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Чем позже обна­ружены ошибки в проектных решениях, тем дороже обходится их исправление; худший вариант — их обнаружение на этапе внедрения. Таким образом, чем раньше группы тестирования начнут выявлять ошибки в АИС, тем ниже стоимость работы над системой. Время на тестирование системы и на исправление обнаруженных ошибок должно быть предусмотрено не только на этапе разработки, но и на этапе проектирования.
Облегчить и увеличить эффективность тестирования призва­ны специальные системы отслеживания ошибок. Их использова­ние позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффектив­ность исправления ошибок, видеть наиболее нестабильные ком­поненты системы, а также поддерживать связь между группой разработчиков и группой тестирования.
Результаты обследования представляют объективную основу для формирования технического задания на АИС [16—18].
Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для раз­работки автоматизированной системы управления.
При разработке технического задания (ТЗ) необходимо ре­шить следующие задачи:
•  установить общую цель создания АИС;
•  установить общие требования к проектируемой системе;
•  разработать и обосновать требования, предъявляемые к ин­формационному, математическому, программному, техни­ческому и технологическому обеспечению;
•  определить состав подсистем и функциональных задач;
•  разработать и обосновать требования, предъявляемые к подсистемам;
•  определить этапы создания системы и сроки их выполнения;
•  провести предварительный расчет затрат на создание сис­темы и определить уровень экономической эффективности ее внедрения;
•  определить состав исполнителей.
Типовые требования к составу и содержанию технического задания приведены в табл. 1.6.
 
 

Эскизный проект предусматривает разработку предваритель­ных проектных решений по системе и ее частям. Выполнение эскизного проектирования не является строго обязательной ста­дией. Если основные проектные решения определены ранее или достаточно очевидны для конкретной АИС и объекта автоматизации, то эта стадия может быть исключена из общей последова­тельности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:
• функции АИС;
•    функции подсистем, их цели и ожидаемый эффект от вне­дрения;
•    состав комплексов задач и отдельных задач;
•    концепция информационной базы и ее укрупненная струк­тура;
•    функции системы управления базой данных;
•    состав вычислительной системы и других технических средств;
•    функции и параметры основных программных средств.
По результатам проделанной работы оформляется, согласо­вывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных реше­ний и достаточном для дальнейшего выполнения работ по созда­нию системы.
В соответствии с ГОСТ 19.102—77 стадия эскизного проек­тирования содержит два этапа: разработку эскизного проекта; утверждение эскизного проекта.
Первый этап разработки состоит из:
•    предварительной разработки структуры входных и выход­ных данных;
•    уточнения методов решения задачи;
• разработки общего описания алгоритма решения задачи;
•    разработки технико-экономического обоснования;
•    разработки пояснительной записки.
При этом допускается объединение и исключение некоторых работ.
Ниже приведен набор документов, который должен и может быть подготовлен по окончании эскизного проектирования.
Обязательные документы:
1)  уточненное техническое задание на проектирование и раз­работку АИС;
2)  спецификация квалификационных требований на АИС;
3)  комплект спецификаций требований на функциональные программные компоненты и описания данных;
4)  спецификация требований на внутренние интерфейсы компонент и интерфейсы с внешней средой;
5)  описание системы управления базой данных, структуры и распределения программных и информационных объектов в базе данных;
6)  проект руководства по защите информации и обеспече­нию надежности функционирования АИС;
7)  предварительный вариант руководства администратора АИС;
8)  предварительный вариант руководства пользователя АИС;
9)  уточненный план реализации проекта;
 
10) уточненный план управления обеспечением качества АИС;
11) пояснительная записка предварительного проекта АИС;
12) уточненный контракт (договор) с заказчиком на деталь­ное проектирование АИС.
Документы, оформляемые по согласованию с заказчиком:
1)  предварительное описание функционирования АИС;
2)  схема потоков данных между функциональными компо­нентами АИС;
3)  уточненная схема архитектуры АИС,  взаимодействия программных и информационных компонент, организации вы­ числительного процесса и распределения ресурсов;
4)  описание показателей качества компонент и требований к ним по этапам разработки АИС;
5)  отчет о технико-экономических показателях,  графике реализации проекта, распределении ресурсов и бюджета;
6)  таблица распределения специалистов по компонентам и по этапам работ;
7)  аттестаты разработчиков на право использования техно­логии и средств автоматизации разработки АИС;
8)  описание требований к составу и формам результирую­щих документов по этапам работ;
9)  план отладки программных компонент, обеспечения ее методами и средствами автоматизации тестирования;
 
10)  предварительное руководство для детального проектиро­вания, программирования и отладки компонент АИС;
11)  предварительный план продажи и внедрения;
12)  описание предварительной структуры базы данных.
На основе технического задания и эскизного проекта разра­батывается технический проект АИС.
Технический проект системы — это техническая документа­ция, содержащая общесистемные проектные решения, алгорит­мы решения задач, а также оценку экономической эффективности АИС и перечень мероприятий по подготовке объекта к вне­дрению.
На этом этапе осуществляется комплекс научно-исследова­тельских и экспериментальных работ для выбора основных про­ектных решений и расчет экономической эффективности систе­мы. Состав и содержание технического проекта приведены в табл. 1.7.
 
 



На стадии «Рабочая документация» осуществляется создание программного продукта и разработка всей сопровождающей до­кументации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АИС в действие и ее эксплуатации, а также для поддержа­ния уровня эксплуатационных характеристик (качества) систе­мы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.
На стадии «Ввод в действие» для АИС устанавливают сле­дующие основные виды испытаний: предварительные испытания, опытная эксплуатация и приемочные испытания. При необходи­мости допускается дополнительно проведение других видов ис­пытаний системы и ее частей.
В зависимости от взаимосвязей компонентов АИС и объекта автоматизации испытания могут быть автономные и комплекс­ные. В автономных испытаниях участвуют компоненты системы. Их проводят по мере готовности частей системы к сдаче в опыт­ную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных компонентов (подсистем) или для системы в целом.
Для планирования проведения всех видов испытаний разра­батывается документ «Программа и методика испытаний». Раз­работчик документа устанавливается в договоре или ТЗ. В каче­стве приложения в документ могут включаться тесты или кон­трольные примеры.
Отладка — наиболее трудоемкий процесс проектирования. Скрытые ошибки иногда проявляются после многолетней экс­плуатации системы. Полностью избежать ошибок невозможно, что обусловлено астрономическим числом вариантов работы системы. Проверить их все на правильность работы в обозримые сроки практически невозможно.
Затраты на выявление и устранение ошибок на более позд­них этапах проектирования возрастают примерно экспоненци­ально (рис. 1.10) [8, 16, 18].
Исследователи насчитывают 169 типов ошибок, сведенных в 19 больших классов:
1)логические;
2)   ошибки манипулирования данными;
3)   ошибки ввода-вывода;
4)   ошибки в вычислениях;
5)   ошибки в пользовательских интерфейсах;

6)  ошибки в операционной системе и вспомогательных про­
граммах;
7)  ошибки компоновки;
8)  ошибки в межпрограммных интерфейсах;
9)  ошибки в интерфейсах «Программа — системное ПО»;
 
10)  ошибки при обращении с внешними устройствами;
11)  ошибки сопряжения с базой данных (БД);
12)  ошибки инициализации БД;
13)  ошибки изменений по запросу извне;
14)  ошибки, связанные с глобальными переменными;
15)  повторяющиеся ошибки;
16)  ошибки в документации;
17)  нарушение технических требований;
18)  неопознанные ошибки;
19)  ошибки оператора.
Не все ошибки исходят от разработчика. По данным разных исследователей, от 6 до 19 % ошибок порождаются ошибками в документации [8, 16, 18].
Соотношение разработки и испытаний на различных этапах проектирования АИС приведено на рис. 1.11.
Данная цепочка лишь условно «вытягивается» в линию. Внутри нее всегда существуют возвратные циклы. Для выявле­ния ошибок разработчики создают специальные тесты и прово­дят этап отладки. Если ошибок не найдено, это еще не означает, что их нет — может быть, тест оказался слишком слабым.
 

Методика отладки учитывает симптомы возможных ошибок:
•   неверная обработка (неправильный ответ, результат) —до 30%;
•   неверная передача управления — 16 %;
•   несовместимость программ с используемыми данными —15%;
•   несовместимость программ по пересылаемым данным —до 9 %.
При разработке отладочных заданий решаются следующие задачи:
•   составление тестов;
•   выбор точек, зон и маршрутов контроля;
•   определение перечня контролируемых величин и порядка фиксации их значений;
•   задание порядка тестирования;
•   оценка достоверности и трудоемкости отладки.
Отлаживаемая программа должна хотя бы один раз прорабо­тать по каждой ветви алгоритма и при этом присвоить перемен­ным ряд значений, захватывая границы диапазона, несколько значений внутри него, нулевые значения и особые точки (если есть). Для специализированных систем разрабатывают специаль­ные языки отладки. Они могут содержать относительно неболь­шое число команд (20—30) с дополнительными настроечными параметрами для решения следующих задач:
•              управления выводом;
•  моделирования процесса исполнения отлаживаемой про­граммы;
•  выдачи состояния компонент памяти в процессе исполне­ния программ;
•  проверки условий достижения определенных состояний в процессе исполнения программы;
•  установления тестовых значений исходных данных;
•  осуществления условных переходов в тестировании в зави­симости от результатов исполнения других макрокоманд или различных тестов;
•  выполнения служебных операций по подготовке програм­мы к тестированию.
Процесс отладки нельзя отнести к полностью формализован­ному, поэтому существуют эмпирические рекомендации по его проведению, которые приведены ниже.
1.  Используйте семантический, заранее продуманный подход к отладке, планируйте процесс отладки и тщательно проекти­руйте тестовые наборы данных с наиболее простых вариантов, исключая наиболее вероятные источники ошибок.
2.  Для упорядочения процесса тестирования собирайте и
анализируйте информацию:
 
•    об особенностях и статистике ошибок;
•    о специфике исходных данных и последовательности из­менения переменных в программе и их взаимном влиянии;
•    о структуре алгоритма и особенностях его программной реализации.
 
3.  В каждый момент времени определяйте местоположение только одной ошибки.
4.  Используйте средства регистрации и отображения инфор­мации об ошибках, включая в программу специальный отладочный код для распечатки выборочных значений переменных, со­общений об окончании отдельных участков программы, трасси­ровки, логических условий и т. п.
5.  Внимательно изучайте полученные выходные данные и сравнивайте их с ожидаемыми, заранее рассчитанными результа­тами.
6.  Обращайте внимание на данные, тщательно анализируйте работу программы при использовании граничных значений и при неправильном вводе; контролируйте типы данных, диапазо­ны, размеры полей и точность.
7.  Используйте анализ потоков данных и потоков управле­ния для проверки корректности и установления областей опре­деления данных для разных маршрутов выполнения программы.
8.  Используйте одновременно различные средства отладки, не останавливаясь на одной возможности. Привлекайте автома­тизированные средства и одновременно ручную отладку и тести­рование, проверяя текст программы с точки зрения функциони­рования с учетом наиболее вероятных ошибок.
9.  Документируйте   все   обнаруженные   и   исправленные ошибки, их отличия, местоположение и тип. Эта информация будет полезна для предупреждения будущих ошибок.
 
10. Измеряйте сложность программ. В программах с высокой сложностью высока вероятность ошибок спецификаций и про­ектирования, а с низкой сложностью — кодирования и канце­лярских ошибок.
11. Для повышения опыта и тренировки в отладке искусст­венно помещайте в программы ошибки. После определенного периода отладки программисту следует указать на оставшиеся и не обнаруженные им ошибки. Подобное «засевание» широко ис­пользуют для оценки числа необнаруженных ошибок (если рав­номерно обнаруживаются и исправляются и искусственные, и реальные ошибки, то по процентному соотношению обнаружен­ных внесенных и реальных ошибок можно предположить, сколь­ко еще их осталось).
Предварительные испытания проводят для определения рабо­тоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления соответствующих документов об их готовности к испытаниям, а также после ознакомления персонала ЛИС с эксплуатационной документацией.
Опытную эксплуатацию системы проводят с целью определе­ния фактических значений количественных и качественных ха­рактеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффек­тивности и корректировки, при необходимости, документации.


и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.