Разработка программного модуля для удаленного администрирования и мониторинга RAID-системы

Обзор программных продуктов для управления RAID-системой. Структура входных и выходных данных. Выбор платформы проектирования. Информационные потребности пользователя. Методика и результаты испытаний программы. Отладка и общие принципы тестирования.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 01.10.2017
Размер файла 1,2 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Составление проекта

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

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

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

Алгоритмизация

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

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

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

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

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

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

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

Программирование

В случае, когда на предыдущем этапе был получен детально разработанный алгоритм, составление программы на выбранном для программирования языке (алгоритмическом языке высокого уровня, автокоде, языке ассемблера или машинном языке) сводится к переводу этого алгоритма на язык программирования. Основные трудности и, следовательно, причины ошибок на этом этапе заключаются, во-первых, в необходимости знания всех требований и ограничений выбранного языка программирования и, во-вторых, в необходимости постоянного внимания ко многим деталям языка, которые приходится учитывать в ходе написания программы. Если этап 2 был выполнен некачественно и алгоритм представлен недостаточно детально, то его доводку придется выполнять «на ходу», во время программирования. Это затруднит процесс программирования-перевода и поведет к возникновению дополнительных ошибок в программе. Чем более процесс программирования будет походить на перевод, чем более механическим будет такой перевод, тем более легким будет составление программы и тем меньше возникнет ошибок на этом этапе, самом щедром на ошибки.

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

После составления программы проводится ее проверка для обнаружения и исправления ошибок, внесенных на этом этапе. Если при проверке обнаруживаются ошибки, допущенные на предыдущем этапе (2), то соответствующие исправления вносятся и в алгоритм, поскольку к нему еще придется обращаться на следующих этапах, и тексты алгоритма и программы должны соответствовать друг другу.

Препарация

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

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

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

Трансляция

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

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

На этапе отладки производится обнаружение с помощью ЭВМ ошибок в программе и их исправление. Этап отладки можно разделить на три подэтапа:

1. Контроль правильности программы.

2. Локализация ошибок.

3. Исправление ошибок.

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

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

На последнем подэтапе производится исправление ошибок, выявленных на втором подэтапе. Исправления вносятся как в программу, так и в алгоритм, если он затрагивается этими исправлениями.

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

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

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

Счет

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

Отчет о работе

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

Модернизация

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

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

2.4 Методика испытаний программы и результаты экспериментальной проверки

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

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

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

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

Отладка и общие принципы тестирования

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

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

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

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

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

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

И локальное, и перекрестное тестирование сопровождается проверкой исходного кода. Если работа тестировщика с системой - это поиск ошибок по их проявлениям в процессе выполнения программы, то работа с исходным кодом позволяет «отловить» ошибки, которые при обычном тестировании проявятся не сразу.

Существует два основных подхода к тестированию:

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

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

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

Алгоритмическое тестирование

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

Функциональное или аналитическое тестирование

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

Содержательное тестирование

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

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

Особенности среды программирования

Среда программирования Microsoft Visual Studio 6.0 и язык программирования в ней Microsoft Visual C++ имеют ряд особенностей, влияющих на тестирование программ:

  Visual C++ является языком программирования высокого уровня, что сильно увеличивает значимость статического (символьного) тестирования;

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

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

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

  большую часть структуры программы в Visual C++ with Microsoft Foundation Classes занимают стандартные, автоматически создаваемые объекты, управляющие работой программы в ответ на действия пользователя. Поэтому ошибки в основном содержатся в алгоритмах процедур, написанных программистом.

Рис. Отладка в среде Visual C++ 6.0

Тестирование программы и его результаты

Представленный программный модуль Агент в составе проекта GUI RAID Manager отвечает за постоянную работоспособность RAID-массива. Поэтому данный модуль должен постоянно работать на компьютере с RAID-системой. По этой причине должна быть обеспечена высокая надежность этого модуля, для того чтобы он не перестал работать по вине критической ошибки.

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

корректность структуры программы;

корректность обработки данных;

устойчивость к ошибочному вводу данных пользователем.

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

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

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

3. Организационно-экономический раздел

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

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

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

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

3.1 Планирование разработки

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

Сетевое планирование

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

Ч Перечень элементарных работ комплекса.

Ч Перечень работ, на которые опираются элементарные работы.

Ч Время выполнения каждой работы.

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

Создание структурной таблицы работ

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

1. Создание графического интерфейса к модулю Менеджер.

2. Разработка протокола для обмена данными между Менеджером и Агентом.

3. Создание модуля для подключения Менеджера к удаленному Агенту.

4. Создание модуля для запуска Агента и поиска подключенных RAID-систем.

5. Разработка модуля для опроса RAID-контроллера в составе Агента.

6. Создание модуля, отвечающего за авторизацию.

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

8. Создание модуля в составе Агента, отвечающего за нотификацию пользователя при сбоях в работе.

9. Разработка мастера начальной установки RAID-системы.

10. Создание модуля для отображения состояния RAID-системы в составе Менеджера.

11. Создание модуля для отображения файла истории.

12. Сборка и отладка модулей.

13. Подготовка документации.

Каждая из этих частей является элементарной частицей комплекса работ по созданию ПП. Обозначим их буквой “A” с добавлением номера работы в соответствии со списком приведенным выше.

программный информационный отладка тестирование

Таблица 3.1 Структурная таблица работ

Работа

Опорные работы

Время

1

A1

-

10

2

A2

-

5

3

A3

A1, A2

5

4

A4

-

9

5

A5

A4

5

6

A6

A3, A5

2

7

A7

A5

4

8

A8

A5

5

9

A9

А3, A5

7

10

A10

А3, A9

9

11

A11

А3, A7

7

12

A12

A6, A8, A10, A11

12

13

A13

A12

7

Пронумеруем работы по рангам:

Таблица 3.2 Проанализированная структурная таблица работ

Работа

Опорные работы

Время

Ранг

Новый номер

1

A1

-

10

1

B1

2

A2

-

5

1

B2

3

A3

A1, A2

5

2

B4

4

A4

-

9

1

B3

5

A5

A4

5

2

B5

6

A6

A3, A5

2

3

B6

7

A7

A5

4

3

B7

8

A8

A5

5

3

B8

9

A9

А3, A5

7

3

B9

10

A10

А3, A9

9

4

B10

11

A11

А3, A7

7

4

B11

12

A12

A6, A8, A10, A11

12

5

B12

13

A13

A12

7

6

B13

Упорядочена структурная таблица работ будет иметь вид:

Сетевой график

Рис. 3.1. Сетевой график

На сетевом графике жирной линией выделен критический путь Т=54 дням. По сетевому графику составим календарный график выполнения проекта.

Рис. 3.2. Календарный график выполнения проекта

3.2 Расчет затрат на создание программного продукта

Метод для расчета затрат на создание ПП

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

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

Ч Разрабатываемое ПО находится на стадии создания конструкторской документации

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

Ч Известны трудоемкость разработки данного ПО.

Затраты на разработку ПП включают в себя следующие составляющие:

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

  Sэ - затраты на эксплуатацию программных и аппаратных средств, реализующих ПП;

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

В результате общие затраты рассчитываются так:

K = Kp + Sэ + Kc

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

Ч на непосредственное проектирование, программирование, отладку и испытание программ в соответствии с требованиями пользователей или заказчика - К1р;

Ч на изготовление опытного образца ПП как продукции производственно-технического назначения - К2р;

Ч на разработку, подготовку и применение технологии и программных средств, в случае автоматизации разработки программ - К3р;

Ч на технологические и реализующие ЭВМ, используемые для автоматизации разработки данного ПП - К4р;

Ч на повышение квалификации специалистов - К5р.

Первые две составляющие К1р и К2р являются непосредственными затратами на создание программных средств. Составляющие К3р и К4р можно рассматривать как затраты, обеспечивающие оснащенность процесса создания ПП. Затраты на подготовку и повышение квалификации К5р наиболее трудно формализовать и учитывать в конкретной разработке программных средств. В нашем случае эта составляющая не учитывается.

Расчет затрат на разработку ПП

Затраты на разработку ПП определяются как частное от деления объема программного продукта Пк и производительности труда Р, коррелируемое на произведение коэффициентов изменения трудоемкости (КИТ) в зависимости от ряда факторов:

где

Пк - объем программы, Кбайт;

Р - показатель интегральной средней производительности труда разработчика, чел/день;

Сij - коэффициенты изменения трудоемкости.

В состав коэффициентов входят:

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

,

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

Ч С12 - изменение трудоемкости при изменении структуры данных. В нашей разработке данный коэффициент не учитывается.

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

,

где Тн - наработка на отказ [час].

Ч С14 - ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ. При использовании создаваемым ПП производительности и памяти реальной ЭВМ менее чем на 50% можно не учитывать эти ограничения.

,

где - реальная загрузка ЭВМ, отн. ед.

Ч С15 - длительность предполагаемой эксплуатации. По экспертным оценкам, увеличение предстоящей длительности эксплуатации ПП на порядок от 1 до 10 лет приводит к увеличению КИТ С15 примерно в 1.5-2 раза. Такую зависимость можно описать логарифмической функцией:

,

где d15 - изменяется в диапазоне от 0.5 до 1, tэ - время предполагаемой эксплуатации ПО.

Ч С16 - изменение трудоемкости при увеличении тиража программы. При переходе от уникального ПП к программам, подлежащим тиражированию, затраты заметно возрастают.

,

N - предполагаемый тираж программ.

Результаты расчета по описанным выше формулам представлены в таблице 3.4.

Таблица 3.4 Результаты расчета коэффициентов изменения трудоемкости

Описание

Данные для расчета

Значение

Пк

объем программы

-

800 Кбайт

Р

интегральной средней производительности труда

-

100 [чел/дн]-1

С11

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

- примерное число операторов ассемблера

2.24

С13

Учет надежности функционирования ПП

часов - наработка на отказ в час

2

С14

Ограничение ресурсов реализующей ЭВМ

= 0,3 - реальная загрузка ЭВМ

0.6

C15

Длительность предполагаемой эксплуатации

Тэ = 1 год - время предполагаемой эксплуатации ПО

0.97

C16

Предполагаемый тираж программ N

N = 5000 - предполагаемый тираж ПО

1,5

Исходя из этих данных рассчитываем затраты на разработку ПП:

К'1P=320,39 (чел/дней)

или, в денежном выражении (при з/п разработчика равной Lзп = 4400 рублей в месяц (при 5-дневке - это 200 рублей в день):

72 408 рублей,

где сс = 0,13 - коэффициент, определяющий процент отчислений в фонд социального страхования. Далее также используется этот коэффициент.

3.3 Расчет затрат на изготовление опытного образца ПП

Затраты на изготовление опытного образца ПП К2р определяются необходимостью обеспечить отчуждение всего комплекса программ от его первичных непосредственных разработчиков. Удельный вес этих затрат находится в пределах 10-15% от общих затрат на разработку К1р.

Для изготовления ПО как продукции производственно-технического назначения необходимо:

Ч изготовить и оформить опытный образец ПО на носителях (как промышленное изделие);

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

Затраты на изготовление носителей программ опытного образца: К2Р1 зависят от типа носителей программ о, лент, дисков (~1% от общих затрат).

Затраты на создание комплекта документации К2Р2 практически пропорциональны объему Пк ПП.

или

,

где 2 = 0,17 - удельная трудоемкость страницы написания документации (6 страниц за 1 день);

q = 50 страниц на 1000 команд языка (при общем количестве 2600 команд используемого языка высокого уровня).

Отсюда получим, что затраты на изготовление опытного образца ПП составляют

К'2P=22 (чел/дней) или

4 972 рубля,

Затраты на технологию и программные средства автоматизации разработки ПП

Данные затраты являются достаточно весомыми, так как при разработке ПО использовались высокоэффективные автоматизированные технологии. Объём и сложность создаваемого ПО значительно влияют на выбор уровня автоматизации технологии и долю в общих затратах на разработку. Встречаются ситуации, при которых затраты на технологию достигают 50 % от общих затрат на разработку K1p.

В нашем случае затраты на технологию будем определять из стоимости на приобретение операционной системы Microsoft Windows 2000 (5000 рублей за экземпляр) - ; автоматизированной системы разработки ПО Microsoft Visual Studio 6.0 (13 000 рублей за экземпляр) - и на пуско-наладку этих средств - (будем считать в размере 10% от стоимости программных средств). При этом, необходимо учесть амортизационную составляющую, характеризующую стоимость данных затрат в фиксированном интервале (при предполагаемом сроке эксплуатации 1 год).

7 920 рублей.

Затраты на ЭВМ, используемые для автоматизации разработки ПП

Затраты на ЭВМ К4Р определяются по формуле

, где

= 10 рублей/час - стоимость машинного времени;

= 23,8 рублей/день - амортизационная составляющая, характеризующая стоимость машинного времени в фиксированном интервале (при стоимости ПК используемого при разработке 30000 рублей и при предполагаемом сроке эксплуатации 5 лет);

- коэффициент, определяющий соответствие технических характеристик ЭВМ требованиям средств разработки;

- затраты на моделирующие ЭВМ (), =2 дня;

Таким образом:

=10 427 рублей

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

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

Итоговые суммарные затраты на разработку ПО

Занесем в таблицу все слагаемые для затрат на разработку ПО.

Суммарные затраты на разработку ПП составляют

К = К1Р + К2Р + К3Р + К4Р.

По расчетам, приведенным выше, получаем

К= 95 727 рублей.

4. Раздел по производственной и экологической безопасности

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

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

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

4.1 Вредные и потенциальноопасные факторы на месте разработчика ПО

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

Поражение электрическим током питающей сети.

Пожароопасность.

Нерациональное освещение.

Неблагоприятный микроклимат.

Излучения экрана монитора.

Шум, возникающий при работе механических и электрических устройств системы.

Психофизиологические перегрузки:

Ч Утомление, связанное с монотонностью работы,

Ч Перенапряжение зрительных анализаторов,

Ч Умственное напряжение,

Ч Эмоциональные перегрузки в большом коллективе,

Ч Физические перегрузки (статические).

Поражающие факторы 1 и 2 не являются источниками постоянно действующей опасности. Их безопасность гарантируется тщательным соблюдением правил техники безопасности эксплуатации системы. Каждый работающий должен ознакомиться с этими правилами, пройти соответствующий инструктаж и следить за соблюдением этих правил. Поражающие факторы 3-8 являются постоянно действующими, возникающими при каждодневной текущей работе.

4.2 Нерациональное освещение

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

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

В компьютерном помещении освещение должно быть совместное - естественное (боковое, через окна в наружных стенах) и искусственное - и соответствовать требованиям СНиП 11-4-79. По конструктивному исполнению искусственное освещение может быть двух видов - общее и комбинированное, когда к общему освещению добавляется местное. В большинстве случаев достаточно иметь общее искусственное освещение (лампы местного освещения могут быть использованы, например, при работе с бумагами).

Анализируя условия работы программиста, получаем следующие требования к производственному освещению:

наименьшая допустимая освещенность для общего освещения составляет 300 лк;

при работе за компьютером желательно, чтобы освещенность рабочего места не превышала 2/3 нормальной освещенности помещения;

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

не следует располагать дисплей непосредственно под источником освещения или вплотную с ним;

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

яркость для блестящих поверхностей более 0.2 кв.м не должна превышать 500 кд/кв.м;

показатель ослепленности не должен превышать 40 единиц;

коэффициент пульсаций 10 - 20 %.

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

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

Работу программиста за компьютером можно отнести к классу точных работ. Контрастность текста при светлом фоне на экране монитора не сильная. Согласно СНиП 11-4-79 освещенность при работе с дисплеем составляет 150 лк при малой контрастности, при средней - 200лк. Если предполагается работа с документами или бумагой, освещенность места разработчика ПО должна быть не менее 300лк.

4.3 Расчет общего освещения

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

Выбираем рекомендованное для машинного зала люминесцентное освещение.

Располагаем светильники рядами вдоль длинной стороны помещения. Будем использовать светильники типа УСП-35 с двумя лампами типа ЛБ-35. Для обеспечения наилучших условий освещения, расстояние между рядами светильников L должно соответствовать отношению:

где h-высота подвеса светильников,

где H = 2.7 м - высота помещения,

hc = 0.2 м - свес светильника,

hp = 0.75 м - высота рабочей поверхности от пола.

h = 2.7-0.2-0.75 = 1.75 [м]

L = л*h = 2.2…2.7 [м]

Длина помещения А = 6 м

Ширина помещения В = 4 м

Количество рядов светильников N найдем из уравнения:

L * (0.33* 2 + N-1) = B

Количество рядов светильников N = 2 ряда.

Согласно нормам, нормируемая минимальная освещенность при общем освещении: Eн = 300 лк.

Так как запыленность воздуха меньше 1 мг/мі, то коэффициент запаса:

Кз = 1.5.

Площадь помещения S = A*B = 6*4 = 26 [мІ].

Так как мы предполагаем создать достаточно равномерное освещение, то коэффициент неравномерности освещения: z = 1.15.

Индекс помещения:

Коэффициенты отражения светового потока принимаем:

от потолкасп = 70%,

от стенсс = 50%,

от поласпола = 10%.

Тогда по таблице находим коэффициент использования светового потока:

з = 0.46.

Так как затенения предполагаем не создавать, то коэффициент затенения:

г = 1.

По таблице находим световой поток лампы ЛБ-35:

Фл = 2500 лм.

Световой поток светильника:

Фсв = 2*Фл = 5000 [лм].

Количество светильников в одном ряду:

Расположение светильников:

Длина светильника lсв = 1.3 м

Количество светильников в ряду М = 3 шт

Количество рядов светильников N = 2 шт

Так как А - М*lсв = 2.1<4*L = 12.8 [м]

(где L - рассчитанное минимальное расстояние между светильниками), то расстояние между светильниками в одном ряду L2 можно сделать равным расстоянию от крайнего светильника в ряду до стены.

Расстояние между рядами L1 при расстоянии крайнего ряда от стены 0.33*L1:

Итак, для нормального освещения комнаты используем 6 светильников типа УСП-35 с двумя лампами типа ЛБ-35.

4.4 Электробезопасность

Помещение комнаты с рабочими компьютерами должно относится к категории помещений с повышенной электроопасностью, то есть:

Относительная влажность воздуха в помещении должна быть не более 75%.

Должна отсутствовать токопроводящая пыль.

Не должно быть повышенной температуры воздуха в помещении (температура постоянно или периодически, более одних суток, превышает +35 єС).

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

Не должно быть токопроводящих полов.

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

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

Опасность прикосновения человека к токоведущим частям электроустановки определяется величиной протекающего через тело человека тока. Пороговым значением является Iпор. = 0,5 мА - допустимая величина тока (согласно ГОСТ 12.1.019-79). Для питания компьютерной системы а также многих других устройств используются однофазные сети переменного тока 220 В / 50 Гц. Поэтому при таком напряжении величина тока проходящего через человека может превышать допустимое значение на несколько порядков.

Эффективной мерой защиты при питании оборудования машинного зала напряжением опасным для жизни человека является защитное заземление. Заземляющим устройством называют совокупность заземлителя (металлического проводника или группы проводников, находящихся в непосредственном соприкосновении с грунтом) и заземляющих проводников, соединяющих заземленные части электроустановки с заземлителем. Если корпус электрооборудования не имеет контакта с землей, то в случае перехода напряжения прикосновение к нему так же опасно, как и прикосновение к токоведущим частям электроустановки. Когда корпус заземляют, образуется ветвь тока, параллельная участку сети, в которую включается человек. Ток замыкания на землю перераспределяется: вследствие малого сопротивления заземляющего устройства - больший ток пойдет через заземляющую систему, и меньший - через человека. При исправном заземлении ток, проходящий через тело человека, становится неопасным. Т.к. помещение компьютерного зала относится к классу помещений без повышенной опасности, то для обеспечения безопасности персонала необходим обычный комплекс профилактических работ, включающий обеспечение надежного заземления всех металлических частей, причем наибольшая допустимая величина сопротивления заземления не должна превышать 4 Ом при мощностях сети менее 1000 Вт.


Подобные документы

  • Понятие и назначение, основы создания RAID–массивов, принципы их работы и законы функционирования. Классификация и разновидности систем RAID, их отличительные признаки, оценка преимуществ и недостатков каждого вида. Тестовая разработка RAID-массива.

    курсовая работа [1,7 M], добавлен 24.04.2010

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

    курсовая работа [81,7 K], добавлен 18.08.2014

  • Основные стадии разработки, принципы тестирования и отладка программного модуля "VFS". Особенности проектирования на языке UML. Методы "грубой силы" и их применение при отладке программы. Вредные факторы, присутствующие на рабочем месте программиста.

    дипломная работа [827,0 K], добавлен 07.03.2012

  • Разработка концептуальной модели базы данных. Реализация алгоритмов и разработка управляющей программы. Разработка структуры системы управления данными. Методика проведения и результаты тестирования. Функционирование разработанного программного модуля.

    курсовая работа [550,5 K], добавлен 08.06.2023

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

    курсовая работа [3,7 M], добавлен 04.12.2014

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

    курсовая работа [421,6 K], добавлен 27.06.2015

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

    дипломная работа [3,4 M], добавлен 19.07.2015

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

    курсовая работа [460,1 K], добавлен 26.06.2015

  • Аппаратные и программные RAID-массивы. Расчет объема массива. Временные затраты на расчет и запись контрольных сумм. Пример распределения файлов по JBOD-массиву. Вероятности отказа каждого диска в массиве. Сравнение стандартных уровней RAID-массивов.

    курсовая работа [3,0 M], добавлен 28.03.2011

  • Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.

    отчет по практике [296,1 K], добавлен 19.04.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.