Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Введение…………..……………………………………………………...…………3
1 Анализ предметной области...………………………………………….…..……6
1.1 Изучение структуры предметной области……………………………..…….12
1.2. Описание общей структуры проекта и его компонентов.………….…..…..20
2 Программная реализация проекта и анализ качества………………....……...30
2.1 Выбор платформы и реализация проекта…………………………..………..30
2.2 Система показателей качества………………………………….…………….40
Заключение………...………...…………………………………………………….49
Глоссарий………………………..………………………………………………...52
Список использованных источников………………………...……...…………...56
Список сокращений……………………………………………….………………60
Приложение А………………………………………………..……..………..……61
Приложение В…………………………………………………...…………….......62
Приложение С…………………………………………………...……………...…63
В процессе функционирования любой организации рано или поздно возникает необходимость в сохранении, структурировании и подсчета информации разного направления об истории и основных этапах ее развития; людях, работавших в ней в разные годы; научных, производственных, спортивных достижениях ее сотрудников и т.д. Данная информация при этом должна быть достоверной и локализованной.
Постепенно с развитием программного обеспечения ЭВМ появились идеи создания управляющих систем, которые позволяли бы накапливать, хранить и обновлять взаимосвязанные данные по целому комплексу решаемых задач, например при автоматизации бухгалтерского учета на предприятии. Эти идеи нашли свое воплощение в системах управления базами данных (СУБД). СУБД взаимодействуют не с локальными, а взаимосвязанными по информации массивами, называемыми базами данных. С появлением персональных компьютеров СУБД становятся наиболее популярным средством обработки табличной информации. Они являются инструментальным средством проектирования банков данных при обработке больших объемов информации.
Такая необходимость возникла в Верховном Суде Республики Хакасия (ВС РХ). Секретарь в своей практической деятельности используют информационные технологии, т.е. хранят информацию в электронном варианте.
В Верховном Суде постоянно ведется учет за судьями, подсудимыми и качеством проведенными судьями дел. Секретарь канцелярии Верховного Суда Республики Хакасия производит заполнение данных о судьях, судах области, данных о проведенными судьями дел. Также секретарь собирает сведения об подсудимых. Затем судьям присваивается количество проведенных ими дел и лиц, участвовавших в каждом деле.
В деятельность секретаря входит:
Секретарь, храня информацию в письменном варианте, часто набирают сведения об подсудимых, о судьях, о мониторингах на компьютере, храня на разных рабочих станциях и при необходимости распечатывают необходимые данные.
Для сокращения временных затрат и упрощения работы по расчету качества дел, проведенными судьями и учета подсудимых, заказчиком было принято решение о необходимости организации и автоматизации оперативного сбора и предоставления информации об судьях, подсудимых, проведенных судьями дел и расчета качества работы судей.
Актуальность данной работы обуславливается тем, что секретарь в своей деятельности используют информационные технологии. Для того чтобы систематизировать данные, необходимые для работы секретаря канцелярии ВС РХ, было создано автоматизированное рабочее место (АРМ) «Расчет качества дел».
Объектом данного исследования является процесс сбора, расчета, хранения, обработки и предоставления информации об проведенных судьями дел, судьях, подсудимых и мониторингах.
Предметом исследования является – автоматизация данного процесса путем создания комплекса программных средств: «Расчет качества проведенных дел».
Использование разработанного программного продукта сократит временные затраты на сбор, расчеты и обработку необходимой информации и тем самым повысит производительность работы секретаря.
Целью данной работы является создание комплекса программных средств, предоставляющего возможность оперативного и своевременного сбора, систематизации, хранения, расчета, обработки и предоставления информации о проведенных дел судьями, работающих в судах, принадлежащих разным городам, о подсудимых и мониторингах, составляемых секретарем канцелярии Верховного Суда Республики Хакасия: позволяющего производить удобный и быстрый расчет качества дел проведенными судьями, создавать отчеты определенного формата.
Для достижения цели были сформулированы следующие задачи:
Методы исследования:
Новизна работы состоит в том, что программный продукт «АРМ секретаря канцелярии Верховного Суда Республики Хакасия» разработан специально для Верховного Суда Республики Хакасия с учетом его особенностей и специфики работы.
До разработки «АРМ секретаря канцелярии Верховного Суда Республики Хакасия» в ВС РХ не было подобных программных продуктов.
До его внедрения в ВС РХ не использовалось никакого программного обеспечения для сбора, хранения и обработки данной информации.
Практическая значимость данного программного продукта состоит в том, что программный продукт может использоваться в других судах при условии аналогичных требований к структуре данных.
Структура и объем работы - пояснительная записка к дипломной работе выполнена на 93 страницах машинописного текста, содержит 7 рисунков, 23 таблиц. Состоит из введения, 4 разделов и заключения. Список использованных литературных и электронных источников содержит 40 наименований.
В первом разделе проводится описание предметной области, описывается информационная среда учреждения, и вносятся предложения по ее автоматизации.
Во втором разделе приведена модель жизненного цикла программного обеспечения (ПО), содержится описание архитектуры и инфологической модели базы.
В третьем разделе обоснован выбор средств реализации проекта, а также представлены основные этапы реализации модулей программного продукта.
В четвертом разделе описывается система показателей качества, проводится анализ результатов тестирования и опытной эксплуатации, а так же представлены предложения по улучшению качества программного обеспечения.
В заключении подведены итоги работы, отмечены преимущества предлагаемого варианта решения, перспективы дальнейшего исследования в этой области.
В приложениях содержатся: структура таблиц базы данных, документированный листинг программы, диаграммы: «сущность-связь», потоков данных, техническое задание.
При разработке программного продукта важным моментом является осознание того, в какой информационной среде он будет использоваться, полноценное исследование данной области позволит достичь максимального эффекта при его использовании. Именно поэтому на стадии анализа необходимо уделить большое внимание описанию предметной области функционирования продукта. Анализ предметной области является первым этапом построения информационной системы. Здесь осуществляется сбор информации об этой области, устанавливаются источники информации, выделяются функциональные области и процессы, происходящие в этих областях.
Работа секретаря требует умения быстро переключаться с одного вида деятельности на другой и хаpактеpизуется широтой и pазнообpазием выполняемых функций. Важнейшая функция секpетаpя - оказание максимальной помощи руководителю и экономия его времени. Эта задача подразумевает выполнение таких работ как:
1. Работа с документами. Этот вид деятельности включает весь комплекс работ, связанных с делопроизводством: оформление документов, направление документов в стpуктуpные подразделения, контроль за сроками исполнения документов, прием документов на подпись руководителю и контроль за правильностью их оформления, организация хранения исполненных документов.
2. Работа со средствами связи. Ведение телефонных переговоров (при отсутствии руководителя на рабочем месте секретарь записывает фамилию и телефон звонившего абонента и, по возможности, интересующий его вопрос), прием и отправка факсов, сообщений по электронной почте. Секретарь обязан также следить за исправностью всех, находящихся в его ведении средств связи, и немедленно вызывать ремонтные службы в случае их неисправности.
3. Работа с посетителями. Включает в себя прием и помощь как обратившимся к секретарю сотрудникам предприятия, так и помощь командированным (направление в нужное подразделение, помощь с устройством в гостиницу). Секретарь организовывает прием сотрудников и других посетителей в установленные часы приема (предварительная запись на прием к руководителю).
4. Подготовка и проведение совещаний. Секретарь должен проинфоpмиpовать приглашенных на совещание по распоряжению руководителя, подготовить список участников, оформить доклада руководителя. Во время проведения совещания секретарь ведет его протокол.
В Верховном Суде Республики Хакасия секретарь канцелярии собирает информацию о проведенных судьями дел за определенное время. Анализируя эту информацию, они составляют мониторинги. Данные, которые содержатся в сущностях:
Кроме того, при хранении она лишь частично систематизируется, степень ее систематизации зависит от руководителя ответственного за ее хранение.
В результате такой работы некоторая информация теряется, и процесс ее восстановления занимает большое количество времени. Результатом работы секретаря являются структурированные данные о судьях, а также мониторинги, готовые для использования на собраниях и других мероприятий.
Как видно из описания работы секретаря с информацией неавтоматизированным путем, отсутствие централизованного хранения такого рода информации затрудняет проводимые вручную анализ и обработку информации, замедляет работу секретаря по ее сбору и систематизации. Кроме того, при смене судьей суда, вся работа по сбору и хранению информации происходит заново, это можно увидеть на рисунке. 1.1.
Рисунок. 1.1. Схема работы секретаря с информацией до внедрения п.о.
В существующей информационной системе основным недостатком является высокая трудоемкость процесса сбора и систематизации информации, а в некоторых случаях и восстановления утраченной.
Основным вариантом решения этой проблемы является автоматизация данных процессов с использованием компьютерных технологий, т.к. в этом случае только эти технологии смогут уменьшить трудоемкость, увеличить скорость работы, обеспечить своевременный сбор и систематизацию информации, долговременное ее хранение.
Для обеспечения процесса своевременного и оперативного сбора и систематизации информации об судьях и подсудимых в Верховном Суде Республики Хакасия и других судах республики и ускорения процессов ее обработки и предоставления планируется разработать программный продукт, который должен обеспечивать:
Программный продукт (ПП) призван упростить процесс получения информации из большого количества исходных данных, что можно увидеть на рисунке. 1.2.
Рисунок. 1.2. Схема работы секретаря, после внедрения п.о.
Модель предметной области – это наши знания о предметной области. Эти знания могут быть неформальные, то есть изложенные человеком экспертом на основе собственного опыта, а также формально с помощью каких либо средств. В качестве таких средств могу выступать текстовые описания предметной области наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ хранения информации крайне неэффективен. Гораздо более информативными и полезными при разработке приложений являются описания предметной области, выполненные при помощи инициализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа Structured Analysis and Design Technique (SADT) диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа и др.. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. И от того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений1.
Для построения моделей предметной области было решено применить методологию SADT. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
Правила SADT включают:
Схема работы с информацией творческой группой не автоматизированным путем и схема усовершенствования изображены с помощью SADT диаграммы на рисунке. 1.3.. Функциональная модель SADT отображает структуру процессов функционирования системы и ее отдельных подсистем, т.е. выполняемые ею действия и связи между этими действиями.
Рисунок. 1.3. Контекстная диаграмма предлагаемого усовершенствования информационной системы
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, что видно на рисунке. 1.4., а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги.
Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок вверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны.
Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
Рисунок. 1.4. Декомпозиция контекстной диаграммы предлагаемого усовершенствования информационной системы
Выводы по изучению структуры предметной области таковы:
1. Выявлены недостатки существующей системы сбора, обработки и предоставления информации (большая трудоемкость, значительные затраты времени) и доказана необходимость автоматизации.
2. Проведено исследование предметной области в организации заказчика, на основании чего составлен полный перечень требуемых функциональных возможностей программы.
От того, насколько правильно будет спроектирована архитектура программного комплекса и отдельных его компонентов, зависят очень многие качества проекта. Так в тесной зависимости от примененной архитектуры находятся способ реализации программного кода, время работы над проектом, в немалой степени от этого будет зависеть примененная модель жизненного цикла и методология работы над проектом.
В этом разделе мы рассмотрим и проанализируем архитектуру системы АРМ «Расчет качества дел» на основе этого анализа разберем структуру информационных потоков в системе, а также составим план развертывания программы
Одним из базовых понятий при проектировании любой информационной системы является модель жизненного цикла (ЖЦ). Жизненный цикл – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации3.
Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Lifecycle Management - PLM).
Известный эксперт по управлению высокотехнологичными проетами Арчибальд так определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р., 2005]:
Жизненный цикл проекта имеет определенные начальную и конечную точки, привязанные к временной шкале. Проект, в своем естественном развитии проходит ряд отдельных фаз.
Жизненный цикл проекта включает все фазы от момента инициации до момента завершения. Переходы от одного этапа к другому редко четко определены, за исключением тех случаев, когда они формально разделяются принятием предложения или получением разрешения на продолжение работы. Однако, в начале концептуальной фазы часто возникают сложности с точным определением момента, когда работу можно уже идентифицировать как проект (в терминах управления проектами), особенно если речь идет о разработке нового продукта или новой услуги.
Существует общее соглашение о выделении четырех обобщенных фаз жизненного цикла (в скобках приведены используемые в различных источниках альтернативные термины):
-концепция (инициация, идентификация, отбор)
-определение (анализ)
-выполнение (практическая реализация или внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.)
- закрытие (завершение, включая оценивание после завершения).
Однако, эти фазы столь широки, что ... необходимы конкретные определения, быть может пяти-десяти основных фаз для каждой категории и подкатегории проекта, обычно с несколькими подфазами, выделяемыми внутри каждой из этих фаз.
Нередко можно наблюдать частичное совмещение или одновременное выполнение фаз проекта, называемое “быстрым проходом” в строительных и инжиниринговых проектах и “параллелизмом” – в военных и аэрокосмических. Это усложняет планирование проекта и координацию усилий его участников, а также делает более важной роль менеджера проектов.”
В общем случае, жизненный цикл определяется моделью и описывается в форме методологии (метода).Модель или парадигма жизненного цикла определяет концептуальный взгляд на организацию жизненного цикла и, часто, основные фазы жизненного цикла и принципы перехода между ними.
Методология (метод) задает комплекс работ, их детальное содержание и ролевую ответственность специалистов на всех этапах выбранной модели жизненного цикла, обычно определяет и саму модель, а также рекомендует практики (best practices), позволяющие максимально эффективно воспользоваться соответствующей методологией и ее моделью.
В индустрии программного обеспечения можно (так как это уже конкретная область приложения концепций и практик проектного управления) и необходимо (для обеспечения возможности управления) более четкое разграничение фаз проекта (что не подразумевает их линейного и последовательного выполнения).
Ниже приведены определения <модели> жизненного цикла программной системы, даваемые, например, в различных вариантах стандартов ГОСТ:
Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999].
Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990].
Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207.
Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения.
В определённом контексте, “модель” и “методология” могут использоваться взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели жизненного цикла, все же, модель чаще подразумевает именно общий принцип организации жизненного цикла, чем детализацию соответствующих работ. Соответственно, определение и выбор модели, в первую очередь, касается вопросов определенности и стабильности требований, жесткости и детализированности плана работ, а также частоты сборки работающих версий создаваемой программной системы.
Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ:
Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем.
Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение.
Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента.
Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом.
Стандарт 12207: Процессы жизненного цикла программного обеспечения
В 1997 году Международная Организация по Стандартизации - ИСО (International Organization for Standardization - ISO) и Международная Электротехническая Комиссия - МЭК (International Electrotechnical Commission - IEC) создали Совместный Технический Комитет по Информационным Технологиям - Joint Technical Committee (JTC1) on Information Technology. Содержание работ JTC1 определено как “стандартизация в области систем и оборудования информационных технологий (включая микропроцессорные системы)”.
В 1989 году этот комитет инициировал разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7 (SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был опубликован 1-го августа 1995 года под заголовком “Software Life Cycle Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла программных средств”.
Цель разработки данного стандарта была определена как создание общего фреймворка по организации жизненного цикла программного обеспечения для формирования общего понимания жизненного цикла ПО всеми заинтересованными сторонами и участниками процесса разработки приобретения, поставки, эксплуатации, поддержки и сопровождения программных систем, а также возможности управления, контроля и совершенствования процессов жизненного цикла.
Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. Детализация, техники и метрики проведения работ – вопрос программной инженерии. Организация последовательности работ – модель жизненного цикла. Совокупность моделей, процессов, техник и организации проектной группы задаются методологией. В частности, выбор и применение метрик оценки качества программной системы и процессов находятся за рамками стандарта 12207, а концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 “Information Technology - Software Process Assessment” (“Оценка процессов <в области> программного обеспечения”).
Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения жизненного цикла программных систем.
Организация стандарта и архитектура жизненного цикла:
Стандарт определяет область его применения, дает ряд важных определений (таких, как заказчик, разработчик, договор, оценка, выпуск – релиз, программный продукт, аттестация и т.п.), процессы жизненного цикла и включает ряд примечаний по процессу и вопросам адаптации стандарта.
Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям – группам процессов (названия представлены с указанием номеров разделов стандарта, следуя определениям на русском и английском языке, определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, соответственно):
Стандарт определяет высокоуровневую архитектуру жизненного цикла. Жизненный цикл начинается с идеи или потребности, которую необходимо удовлетворить с использованием программных средств (может быть и не только их). Архитектура строится как набор процессов и взаимных связей между ними. Например, основные процессы жизненного цикла обращаются к вспомогательным процессам, в то время, как организационные процессы действуют на всем протяжении жизненного цикла и связаны с основными процессами.
Дерево процессов жизненного цикла представляет собой структуру декомпозиции жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция процессов строится на основе двух важнейших принципов , определяющих правила разбиения (partitioning) жизненного цикла на составляющие процессы.
Эти принципы:
- задачи в процессе являются функционально связанными;
- связь между процессами – минимальна;
- если функция используется более, чем одним процессом, она сама является процессом;
- если Процесс Y используется Процессом X и только им, значит Процесс Y принадлежит (является его частью или его задачей) Процессу X, за исключением случаев потенциального использования Процесса Y в других процессах в будущем.
Каждый процесс находится под ответственностью конкретного лица (управляется и/или контролируется им), определенного для заданного жизненного цикла, например, в виде роли в проектной команде;
- функция, чьи части находятся в компетенции различных лиц, не может рассматриваться как самостоятельный процесс.
Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит следующим образом:
- группа процессов;;
- процессы;
- работы;
- задачи.
В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:
“P” – Plan – Планирование
“D” – Do – Выполнение
“C” – Check – Проверка
“A” – Act – Реакция (действие)
Рассмотрим вкратце, какие работы составляют процессы жизненного цикла, помня, что полное определение работ, как и определение составляющих их задач, дано непосредственно в стандарте. Ниже приведен краткий обзор основных процессов жизненного цикла, явно демонстрирующий связь вопросов, касающихся непосредственно самой программной системы, с системными аспектами ее функционирования и обеспечения ее эксплуатации.
Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта):
Inititation – инициирование (подготовка)
Request-for-proposal preparation – подготовка запроса на предложение (подготовка заявки на подряд)
Contract preparation and update –подготовка и корректировка договора
Supplier monitoring – мониторинг поставщика (надзор за поставщиком)
Acceptance and completion – приемка и завершение (приемка и закрытие договора)
Все работы проводятся в рамках проектного подхода.
Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы также проводятся с использованием проектного подхода. Процесс включает следующие работы:
Inititation – инициирование (подготовка)
Preparation of response – подготовка предложения (подготовка ответа)
Contract – разработка контракта (подготовка договора)
Planning - планирование
Execution and control – выполнение и контроль
Review and evaluation –проверка и оценка
Delivery and completion – поставка и завершение (поставка и закрытие договора)
Разработка (5.3)
Процесс разработки определяет работы и задачи разработчика. Процесс состоит из следующих работ:
Process implementation – определение процесса (подготовка процесса)
System requirements analysis – анализ системных требований (анализ требований к системе)
System design – проектирование системы (проектирование системной архитектуры)
Software requirements analysis – анализ программных требований (анализ требований к программным средствам)
Software architectural design – проектирование программной архитектуры
Software detailed design – детальное проектирование программной системы (техническое проектирование программных средств)
Software coding and testing – кодирование и тестирование (программирование и тестирование программных средств)
Software integration – интеграция программной системы (сборка программных средств)
Software qualification testing – квалификационные испытания программных средств
System integration – интеграция системы в целом (сборка системы)
System qualification testing – квалификационные испытания системы
Software installation – установка (ввод в действие)
Software acceptance support – обеспечение приемки программных средств
Стандарт отмечает, что работы проводятся с использованием проектного подхода и могут пересекаться по времени, т.е. проводиться одновременно или с наложением, а также могут предполагать рекурсию и разбиение на итерации.
Эксплуатация (5.4)
Процесс разработки определяет работы и задачи оператора службы поддержки. Процесс включает следующие работы:
Process implementation – определение процесса (подготовка процесса)
Operational testing – операционное тестирование (эксплуатационные испытания)
System operation – эксплуатация системы
User support – поддержка пользователя
Сопровождение (5.5)
Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения. Процесс включает следующие работы:
Process implementation – определение процесса (подготовка процесса)
Problem and modification analysis – анализ проблем и изменений
Modification implementation – внесение изменений
Maintenance review/acceptance – проверка и приемка при сопровождении
Migration – миграция (перенос)
Software retirement – вывод программной системы из эксплуатации (снятие с эксплуатации)
Важно понимать, что стандарт 12207 не определяет последовательность и разбиение выполнения процессов во времени, адресуя этот вопрос также работам по адаптации стандарта к конкретным условиям и окружению и применению выбранных моделей, практик, техник и т.п.
Адаптация стандарта
Адаптация стандарта подразумевает применение требований стандарта к конкретному проекту или проектам, например, в рамках создания внутрикорпоративных регламентов ведения проектов программного обеспечения.
Адаптация включает следующие виды работ:
Определение исходной информации для адаптации стандарта
Определение условий выполнения проекта
Отбор процессов, работ и задач, используемых в проекте или соответствующих регламентах
Документирование требований, решений и процессов, связанных с адаптацией и полученных в ее результате
Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного цикла, а также применение соответствующих методологий, детализирующих процедуры выполнения процессов, работ и задач в рамках заданных границ (содержания) жизненного цикла программного обеспечения и организационной структуры и ролевой ответственности в конкретной организации (ее подразделении) и/или в проектной группе.
Необходимо отметить, что существует еще один стандарт жизненного цикла - ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации процессов жизненного цикла системного уровня (Life Cycle Processes – System) и включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию жизненного цикла к конкретным требованиям и ограничениям, существующим или принятым в конкретной организации/подразделении или для заданного проекта.
В настоящее время остаются распространенными две модели жизненного цикла программного обеспечения, которые многие специалисты считают наиболее перспективными: спиральная и эволюционная.
При использовании спиральной модели ЖЦ для проектирования комплекса основной упор делается на начальные этапы: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии комплекса, на нем уточняются цели и характеристики проекта, оценивается его качество, и планируются работы следующего витка спирали.
В случае спиральной модели процесса разработки программного обеспечения последовательность: анализ требований – проектирование – реализация – тестирование – выполняется более одного раза. Для этого может быть несколько причин. Основная причина обычно связана с необходимостью предупреждения рисков.
Другой причиной может быть необходимость предоставить заказчику частичную версию проекта для получения отзывов и пожеланий. Если разрабатываемая программа достаточно сложна, необходимо выполнять промежуточные итерации, не откладывая эту фазу на самый конец, как это предписывает, например, каскадная модель. Общая же идея спирального процесса заключается в том, чтобы на каждой итерации строить очередную версию программы, используя в качестве основы ее предыдущую версию.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. При спиральном цикле возможно неполное завершение работ на каждом этапе с переходом на следующий этап.
При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. При этом достигается главная задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований, что в конечном итоге способствует получению продукта максимально соответствующего требованиям заказчика.
Эволюционная модель жизненного цикла является своего рода развитием спиральной. Основное ее отличие заключается в том, что в начале работ определяются не все требования. Работа ведется итерациями, каждая из которых состоит из четырех этапов.
На этапе планирования осуществляется сбор или дополнение требований и дальнейшее планирование проекта. Затем, на основе результатов первого этапа, анализируются риски, и принимается решение о целесообразности дальнейшей работы над проектом.
Далее идет конструирование, по сути – реализация запланированных изменений в программе.
Наконец, новая версия продукта демонстрируется заказчику, который проводит оценку, и начинается новая итерация с планирования4.
При построении комплекса программных средств в качестве модели жизненного цикла была выбрана спиральная модель, состоящая из 4 фаз:
На фазе анализа были определены функции, которые должны быть реализованы в программе. Выделены наиболее приоритетные из них, требующие проработки в первую очередь. Определение требований к автоматизации процессов хранения и предоставления информации о судьях проводилось секретарем ВС РХ.
На фазе проектирования ведущий консультант принимал участие в техническом проектировании системы. Его участие заключалось в уточнении и дополнении требований к системе.
При этом более детально рассматривались информационные потоки и процессы, протекающие внутри системы. Интерфейс ПП создавался путем анализа вносимой информации. Тут же был определен состав необходимой документации.
На фазе построения была выполнена непосредственно сама разработка комплекса приложений и базы данных. На данной фазе разработчик произвел построение реальной системы на основе полученных в предыдущих фазах моделей.
На фазе внедрения производилось обучение секретаря работе с программой. Для этого им было предоставлено руководство пользователя.
Следует отметить, что, несмотря на то, что спиральная модель делает упор на этап анализа и проектирования, она вовсе не исключает изменение требований на более поздних этапах разработки.
Из выше описанного можно увидеть, что спиральная модель жизненного цикла с ее итерациями образует единую схему проектирования, что позволяет обеспечить эффективное использование и производить обновление разработанного программного продукта. Последнее особенно важно, поскольку в дальнейшем предполагается сопровождение и развитие проекта в течение длительного времени и разными разработчиками.
План развертывания комплекса - при проектировании программного обеспечения и, особенно, программных комплексов очень важно изначально продумать стратегию внедрения и использования разрабатываемого программного продукта. Такое планирование помогает изначально определить некоторые важные особенности работы проекта и правильно распределить нагрузку на все компоненты системы.
Для обеспечения наибольшей гибкости и мобильности в удобства построения программный комплекс был разработан как два отдельных компонента: программа для отображения, изменения, добавления данных (CourtClient) и общая для всех программ БД.
Для начала работы необходимо расположить БД на общем ресурсе и при запуске программы указать на нее. Такой процесс представляет собой следующую последовательность действий:
Скопировать свободно распространяемую программу CourtClient (модуль доступа к данным) на рабочие станции и приступить к работе.
Данное ПС реализуется как пакет программ, обеспечивающий легкое проектирование реализацию и поддержку. Главными требованиями организации, положенными в основу при разработке программы: легкое управление, простота вычислений, модульность и расширяемость. Поэтому программа скомпонована в виде отдельного файла объектного кода: модуль для отображения, изменения, добавления данных в БД (CourtClient).
Рассмотрим схему построения ПС на уровне модуля для отображения, изменения, добавления данных в БД (CourtClient).
Функции: организация пользовательского интерфейса, организация интерфейса с БД, сохранение данных в БД, вычисление данных, кэширование записей, обеспечение целостности БД, предупреждение удаления записей из БД, выдача отчетов.
Для создания компонентов программы необходимо построить модель, описывающую их поведение и структуру, а для создания базы данных, необходимо описать данные, с которыми будут работать программа. То есть, необходимо создать модель программы, рассматривающую ее как информационную систему и описать структуру данных. Построение такой модели является одним из этапов разработки программного продукта.
В качестве средств моделирования применяются так называемые языки моделирования. В настоящее время применяются несколько основных языков моделирования: SADT, Data Flow Diagram (DFD), Entity-Relationship (ERD).
Каждый из них имеет свои цели и применение. Для моделирования структуры программных модулей используются языки моделирования потоков данных, одним из наиболее проверенных и испытанных из них является DFD.
Именно DFD и использовался для построения модели процессов происходящих в модулях. Для описания же базы данных, используемой в комплексе, использовался другой, не менее известный, язык моделирования «сущность-связь» или ERD. ERD-диаграммы.
Диаграмма потоков данных (DFD) является основным средством проектирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных.
Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Построение логической модели комплекса - для эффективного проектирования комплекса на стадии анализа были выделены все необходимые функции его компонентов (приложений). Это позволило упростить процесс разработки, путем последовательного кодирования каждой подсистемы программного комплекса.
Для приложений были выделен следующий модуль:
Модуль для отображения, изменения, добавления данных:
Построение инфологической модели базы данных:
Для составления инфологической модели разрабатываемой системы выделим информационные объекты и процессы.
Информационные объекты:
Информационные процессы, входящие в область действия автоматизированной системы:
Рассмотрим представленные информационные объекты более подробно.
Судьи. Содержит личные данные судей, главная сущность со следующими атрибутами:
Подсудимые. Содержит личные данные подсудимого, главная сущность со следующими атрибутами:
Вся информация, вносимая в сущности, может быть сохранена в «классической форме». При нормализации она разбиваются на таблицы, которые четко отражают содержимое сущностей.
Выводами по описанию общей структуры проекта и его компонентов, выступает следующее:
После того, как была разработана архитектура программного продукта, встает вопрос выбора аппаратной платформы и средств программной реализации. Это немаловажно, поскольку от выбранной платформы будет зависеть область распространения и надежность созданного программного средства, а от средства программной реализации простота дальнейшего сопровождения и модернизации, это может стать серьезной проблемой, если в дальнейшем сопровождением и модернизацией будет заниматься человек, не имевший отношения к разработке.
Комплекс программных средств для сбора, хранения и предоставления информации должен обеспечить простое и оперативное добавление данных, полностью отражать внесенную информацию.
Созданные проекты должны использовать компьютерные сети (локальные) и иметь возможность внедрения функций, не предусмотренных при разработке всей системы путем внешних подключаемых модулей или изменением каких-нибудь существующих. Разработав такую систему, можно будет контролировать процесс сбора, хранения, обработки и предоставления информации с минимальными затратами на сопровождение.
Сегодняшний рынок программного обеспечения предъявляет большие требования к создаваемым проектам. Например, для современных программных средств важными требованиями являются переносимость, мультиплатформенность и масштабируемость. Под переносимостью здесь подразумевается возможность использовать программное средство на разных программно-аппаратных платформах без существенной переработки кода.
А масштабируемость подразумевает добавление новых функций и свойств программного средства с минимальным изменением всего кода в целом. Идеальным является вариант, который позволяет наращивать мощность вычислительной системы без изменения основного кода, лишь добавляя новые модули5.
Поэтому при разработке учитывались оба этих требования. Естественно, создать более или менее сложное ПС, которое работало бы на всех известных платформах, практически невозможно, но следует стремиться обеспечить его функциональность, хотя бы, на самых распространенных платформах.
При исследовании программно-аппаратной обеспеченности Верховного Суда Республики Хакасия (где создается и будет использован данный программный продукт) было выявлено, что все аппаратное обеспечение составляют IBM PC совместимые машины.
Исходя из этого, было принято решение разрабатывать ПС именно для этой системы. Выбор программной платформы базировался на результатах этих же исследований. Проанализировав системное программное обеспечение IBM PC совместимых машин, были получены следующие результаты: на всех компьютерах гимназии установлены ОС семейства Windows.
Поэтому, а так же из соображения, что программное обеспечение должно функционировать как можно на большем количестве платформ, было принято решение разрабатывать ПС с таким расчетом, чтобы обеспечить функционирование, как его отдельных компонентов, так и всего комплекса в целом на программной платформе Windows.
Выбор среды разработки программного продукта является важной и неотъемлемой частью. В качестве основной среды разработки модуля для работы с БД программного комплекса (CourtClient) использовалась среда разработки Borland Delphi 7.0.
Важный аспект применения Delphi заключается в широком использовании технологии быстрой разработки приложений (Rapid Application Development, RAD). Это позволяет разрабатывать приложения в несколько раз быстрее более традиционных способов разработки. Например, при использовании традиционных методов программирования, создание графического интерфейса программы, включая обработку событий мыши, клавиатуры, включение в программу изображений и звука даже при использовании специальных API занимало довольно большую часть времени программиста и зачастую, программный код, отвечающий за интерфейс, занимал около 80-90% от общего кода программы.
Использование этого продукта обеспечивает единую среду разработки. Delphi – одна из самых мощных систем, позволяющих на самом современном уровне создавать как отдельные прикладные программы, так и разветвленные комплексы, предназначенные для работы в корпоративных сетях и в Internet. В качестве основного языка программирования в Delphi применяется Object Pascal. Это объектно-ориентированный язык программирования позволяющий организовать современный подход к построению программ и систем разного уровня сложности.
Одним из методов решения стало появление концепции визуальных языков программирования, где разработка интерфейса приложений упрощалась за счет библиотеки стандартных элементов управления. Такая концепция была впервые реализована в языке Microsoft Visual Basic. Но компания Borland пошла гораздо дальше и расширила ее до RAD. Тем самым, внедрив возможность не только быстро строить из готовых элементов интерфейс приложения, но так же включать другие объекты, реализующие различные аспекты логики программы, например, объекты доступа к базам данных или взаимодействия с сетью.
Borland Delphi 7.0 позволяет:
Это список, только самых основных возможностей Borland Delphi 7.0. Большинство из них соответствует поставленной перед нами задаче о разработке мультиплатформенного приложения, работающего с большими объемами данных, локальными вычислительными сетями6.
При анализе существующих популярных СУБД наиболее соответствующей одновременно всем необходимым требованиям стала СУБД MS Access.
Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.
MS Access – это качественная СУБД, которая приобрела довольно большую популярность во всем мире. Особенно, где дело касается разработки некоммерческих программных проектов по обработке данных.
Перечислим основные возможности MS Access:
Достоинством MS Access является то, что она имеет простой графический интерфейс, который позволяет создавать не только базы данных, но простые и сложные приложения. В отличии от многих СУБД, MS Access хранит всю информацию в одном файле, позволяет не только вводить данные, но и контролировать их7.
Все эти возможности отлично подходят для реализации целей разрабатываемого проекта.
Под взаимодействием следует понимать то, посредством каких механизмов происходят действия над информацией.
После того как пользователь выбрал то или иное действие в программе работают механизмы, направленные на достижение цели заложенной разработчиком.
Все взаимодействия, будь то создание отчета или изменения данных представленных в компонентах формы, реализованы в виде запросов на выборку. Запросы на выборку применяются в качестве средства поиска записей по базе данных, которые удовлетворяют пользовательским условиям, а также для добавления и изменения данных о судьях, проведенных делах и подсудимых.
Все запросы выполнены в ручную для обеспечения полного контроля за операциями с данными и осуществляют сборку из одной или нескольких таблиц. Запросы реализованы с помощью языка структурных запросов – Structured Query Language (SQL).
Достоинством реализации всех действий с помощью запросов является то, что существует возможность работы сразу с несколькими операциями. Тогда как формы, основанные на таблицах блокируют доступ к таблице и дальнейшая работа возможна только после закрытия соответствующей формы.
Реализация базовых операций - в проекте выделены следующие базовые операции: инициализация запроса, открытие и закрытие формы, создание отчета.
Пример выполнения операции: операция инициализации запроса вызывается пользователем, хотя он и не видит этого на экране, результатом чего является открытие отчета или изменение значений компонентов формы, отражающие результаты исполнения запроса.
Реализация действий производилась с помощью ActiveX Data Objects (ADO) и средств Borland Delphi 7.0.
База данных создана средствами СУБД Access 2003. На рисунке. 2.1. представлена одна из основных сущностей – сущность судей. Фрагменты схемы данных расположены в одном файле представляющем БД, что, не нарушает логики работы БД. Этот шаг предпринят, в связи с тем что, представленные в этих схемах данных сущности достаточно самостоятельные, а размещение информации в данных структурах в отдельных файлах усложнило бы подключение к оболочкам, реализованным с помощью среды программирования Borland Delphi7.0. через компоненты ADO.
Рисунок. 2.1. Сущность судьи
Требовалось бы каждый раз при запуске программ производить тройной интерфейс с базой данных.
Это не безопасно и в этом случае пришлось бы провести отдельную работу для, предупреждения неправильного подключения файлов БД (какой файл к какой форме относится. Принятое решение позволяет использовать одну ConnetionString в которую записывается путь к файлу, параметры аутентификации и название файла БД, и один компонент позволяющий работать с SQL запросами к таблицам в БД - AdoQuery.
Данные в БД представлены в виде таблиц, информация в них нормализованная и разделена на три сущности судьи, подсудимые, мониторинги. Структура таблиц базы данных, созданная с использованием системы драйверов ADO. Все таблицы имеют поля: название поля, тип поля, размер поля и индекс.
Разработка пользовательского интерфейса была проведена с помощью среды программирования Borland Delphi 7.0.. Интерфейс для программного комплекса разрабатывался с учетом того, что секретарю необходимо будет вносить не только данные о судьях, но и о подсудимых. Основная окно программы выполнена в виде формы, имеющей три вкладки: «Приговоры и постановления по существу», «Прочие судебные решения», «Подсчеты по судьям» Программа для добавления, редактирования, удаления данных (CourtClient).
При нажатии на кнопку «Начало работы» открывается основная форма «АРМ секретаря канцелярии ВС РХ», представлено на рисунке. 2.2.. Данная форма содержит главное меню, которое содержит пункты: файл, имеет команду «выход»; правка, имеет команды «Добавить судью», «Редактировать», «Удалить»; сортировка, имеет команду «По фамилии»; справочники, имеет команду «Список судов», «Кодексы РФ»; отчеты, распечатка «По судье», «По судам» и «Общий отчет»; Подсудимые, выполняет переход на вторичную форму «Подсудимые»; Справка, имеет пункт «О программе» и «Помощь».
Рисунок. 2.2. Главная кнопочная форма
Интерфейс этого модуля реализован таким образом, что при запуске программы открывается главная форма, каждая новая форма открывается из нее при нажатии на соответствующую кнопку. На главной форме расположены следующие кнопки: «Начало работы» - осуществляет переход к форме для работы с информацией по основным сущностям. «О программе» - осуществляет переход к форме «О программе», где расположена информация о программном продукте и об авторе программы. «Выход» - при нажатии на кнопку происходит закрытие программы. Названия кнопок соответствует производимому действию это делает интерфейс интуитивно понятным.
Также находятся три вкладки: «Приговоры и постановления по существу», «Прочие судебные решения», «Подсчеты по судьям», при нажатии на которые отображаются другие вкладки с данными. На вкладке «Приговоры и постановления по существу» имеются вкладки: «Всего обжаловано», «Без изменений», «Отменено», «Изменено». Так же на каждой из этих вкладок расположены кнопки для вычислений выбранного раздела и поля, в которых отображаются результаты вычислений. Вкладка «Прочие судебные решения» содержит две вкладки: «Оставлено без изменений», «Отменено, изменено» представленный на рисунке. 2.3. Вкладка «Подсчеты по судьям» содержит данные по отдельно взятому судье, а так же поля и кнопки необходимые для расчета качества проведения дел.
Рисунок. 2.3. Вкладка подсчета по судьям
Защищенность ПП - способность противодействовать несанкционированному вмешательству в нормальный процесс его функционирования, а также попыткам хищения, незаконной модификации, использования, копирования или разрушения самого ПП, его составляющих, данных и информации, входящих в состав ПП, доступных ему в процессе выполнения или заложенных в него во время разработки.
Автоматизированное рабочее место «Расчет качества дел» защищено паролем, для обеспечения безопасности данных. При входе в программу секретарю необходимо будет выбрать логин и ввести пароль. При введении правильного пароля открывается главная кнопочная форма «Подсчет качества дел». При неправильном введении пароля секретарю необходимо будет повторить ввод пароля. Иначе вход в программу будет невозможен.
Выводы по данному разделу следующие:
1. Проведен анализ существующих средств разработки и их возможностей. На основании проведенного анализа обоснован выбор средств разработки для создания программ. Средством разработки выбрана среда программирования Delphi 7.0.
2. Завершена стадия кодирования. Создана общая структура программного средства, позволяющая модифицировать программный продукт, исправлять существующие и создавать новые компоненты.
3. Определены общие принципы построения интерфейса. Модель интерфейса программного средства была реализована в соответствии с этими принципами.
В данном разделе описывается методика тестирования программной системы, приводятся результаты тестовых испытаний и опытной эксплуатации. Выносятся предложения по улучшению качества программы.
Этап отладки и тестирования программы преследует цель выявить и устранить ошибки в разработанном приложении, а также определить, в какой мере разработанная программа удовлетворяет требованиям, сформулированным в техническом задании. Оценка качества позволит выявить недочеты и, возможно, определить новые направления работы и пути усовершенствования продукта8.
Работы по отладке и тестированию программ характеризуются большой степенью повторяемости и являются наиболее утомительными и дорогостоящими в плане временных затрат. В связи с этим уделяется большое внимание разработке и использованию различных системных и инструментальных средств, автоматизирующих выполнение работ на данном этапе.
Все модули по типу кода и внутреннего устройства можно разбить на группы:
Модуль добавления, редактирования и удаления записей:
Таким образом, имеется один модуль, но со всеми необходимыми возможностями. Основная задача, которая перед нами встает: проверить выполнение функций заложенных в этом модуле.
Выбор критериев для оценки качества программы зависит от ее назначения и выполняемых функций, от условий разработки, используемых алгоритмов, и т.д. Поэтому составление системы показателей качества сопровождается анализом всех этих параметров.
Сама система показателей качества ПО включает в себя такие параметры, как:
Разрабатываемые программы не содержат сложных алгоритмов обработки данных, но CourtClient оперирует важными данными, поэтому требуется тщательное тестирование отказоустойчивости этого компонента программного пакета. Нельзя допустить, чтобы из-за ошибки в коде были уничтожены данные, собираемые в течении большого временного периода или возникли проблемы по их сохранению.
Поскольку пакет прикладных программ создан и откомпилирован в среде Borland Delphi 7.0, то начальные требования к возможностям аппаратной части, на которой будут функционировать компоненты пакета прикладных программ, невелики.
Теоретически для исполнения кода достаточно иметь в качестве центрального процессора Intel 486, но программы комплекса работают с большими объемами информации, поэтому необходимо дополнительно протестировать производительность и объем используемых ресурсов этих компонентов на различных аппаратных конфигурациях.
Пользовательский интерфейс должен предоставлять легкий доступ к основным функциям системы (просмотр, добавление данных, создание отчетов), поэтому потребуется также оценить понятность интерфейса.
Правильность построения интерфейса особенно важна в данном программном продукте, поскольку он разрабатывается для неопытных пользователей компьютеров, возможно, никогда не видевших, следовательно, интерфейс должен быть непросто понятным всем, но и позволять работать с программным продуктом не менее комфортно, чем с использованием традиционных средств.
Поскольку система изначально рассчитывается на дальнейшее развитие и усовершенствование, важно, чтобы архитектура программы предоставляла возможность легкого изменения, добавления модулей и т.д.
Поэтому нужно заранее оценить расширяемость как самой архитектуры комплекса новыми модулями, так и возможность расширения каждого модуля новыми функциями.
Итак, оценка качества разработанного комплекса прикладных программ будет проведена по следующим показателям:
Хотя контроль качества необходим на протяжении всей работы над проектом, наибольшее внимание должно быть уделено тестированию на этапе реализации, так как именно оно позволяет выявить ошибки, которые могут привести к потерям данных – самом ценном во всей системе. А чтобы тестирование было эффективным, нужно заранее выбрать и спланировать методы тестирования.
Метод модульного тестирования основан на рассмотрении анализируемого артефакта с точки зрения его структуры, формы и назначения; здесь применяются формальные методы проектирования.
Unit-тестирование часто ассоциируется со структурным тестированием, но это происходит, потому что на этом уровне тестирующие обычно не имеют четко определенных требований.
Модули программ достаточно невелики, поскольку изначально была четко определена область ответственности каждого из них и в случае если у модуля оказывалось слишком много обязанностей он разбивался на несколько более узкоспециализированных модулей.
Сложный код имеется только в модулях, выполняющих манипуляции с данными, к каковым относится, например, модуль заполнения данных по сущности судья, модуль заполнения данных по сущности подсудимые.
Поскольку заполнение данных в данном комплексе программ является самой сложной частью, основное внимание при тестировании должно быть уделено именно заполнению данных в данных модулях программы.
Тестирование на этапе анализа:
Оценка моделей:
Модель предметной области полностью описывает текущую работу автоматизируемой подсистемы работы секретаря по подготовке процесса сбора, хранения и предоставления информации мониторингов, сведений об судьях, подсудимых и пригодна для выявления всех функции, их взаимосвязей и порядка выполнения, которые должна выполнять новая система. Все модели полны и непротиворечивы.
Оценка требований:
Перечисленные в техническом задании требования представляются адекватными и выполнимыми в поставленные сроки.
Тестирование на этапе проектирования:
Оценка проекта:
Проект является реально реализуемым в обозначенные сроки. Это можно утверждать на основании анализа технического задания: разрабатываемая система не содержит каких-либо весьма сложных алгоритмов, имеет реализуемый стандартными средствами интерфейс и допускает использование RAD-среды разработки, что соответствует квалификации разработчика занятого в работе над проектом.
Тестирование диаграмм:
Модель архитектуры, представленная в форме DFD-диаграммы отображает модульный состав проекта, точно указывает взаимосвязь различных частей программы и компонентов программного комплекса. Диаграмма сущностей представляется полной, показывающей все участвующие в системе объекты и их взаимосвязи и характеристики, и пригодна для построения конечной схемы данных разрабатываемой информационной системы.
Тестирование на этапе реализации:
Поскольку на момент тестирования в БД было введено мало данных, была создана и заполнена большим количеством случайных данных тестовая база данных. Поиск в БД информации (тестирование работы программы для получения данных (CourtClient) показал стабильность и корректность работы модуля при достаточно приемлемой эффективности:
Инициализация соединения с БД, происходящая в момент запуска программ комплекса, при первом запуске занимает 5 секунд и при повторном запуске - не более 5 секунд.
Чтобы оценить расширяемость, можно рассмотреть архитектуру построения программы. Внесение изменений в уже существующие компоненты возможно. Этому способствует и применение методологии RAD, и снабжение процедур комментариями.
Тестирование в реальном масштабе времени:
Это тестирование проводится с целью оценки работоспособности программы и удобства ее интерфейса.
Оценка интерфейса производилась с помощью опроса пользователей. Каждый пользователь высказывает свое мнение об интерфейсе. Помимо этого субъективного мнения, в качестве более объективной оценки собрана статистика работы пользователей: время, за которое пользователь вносил информацию и количество неверных действий, которые они совершили при работе.
Для программы внесения данных в первую очередь проверялась работа запросов на выборку (заполнение), вносились тестовые данные, затем предпринималась попытка сохранить информацию, внесенную в компоненты интерфейса.
Время внесения данных в формы не превышала 2 минут, что говорит об интуитивной понятности интерфейса программы.
Процесс добавления, изменения и удаления данных очень удобен и интуитивно понятен.
Проверялась работа запросов на выборку, отображаются ли тестовые данные в компонентах интерфейса.
Время поиска данных не превышало так же 1 минут, поэтому можно сделать вывод, что интерфейс интуитивно понятен.
Что касается пользовательского интерфейса, то он оказался очень удобным. Работа с вкладками показалась пользователям наглядной и понятной, так как не нужно было переходить с формы на форму, а вся работы велась в одной форме, предоставляющей систематизированную информацию.
Выводы по качеству программного продукта:
По результатам тестирования можно сделать следующие заключения:
Пользовательский интерфейс обладает понятностью и достаточной функциональностью.
Программа имеет высокую устойчивость в работе.
Требования к ресурсам зависят от объема базы данных; в общем, требования к ресурсам приемлемы для нормального функционирования на базе программного и аппаратного обеспечения Верховного Суда Республики Хакасия.
Надежность комплекса, помимо удачно проведенного тестирования, обеспечивают еще и тот факт что, все компоненты комплекса были созданы с использованием высококачественных средств разработки, предоставляющих средства для создания надежных программных продуктов.
Программа имеет все предпосылки для развития. Расширяемость программы делает возможным дальнейшие изменения. В целом, тестирование показало готовность к работе, но некоторую незаконченность программного продукта в текущей версии.
Результаты тестирования отображены в следующей таблице:
|
Ошибки |
Комментарии |
Кол-во |
|
В именах переменных |
Используемые имена объектов отличались от имен, объявленных в разделе объявления переменных. |
3 |
|
Пропуск символа «&» при формировании запроса |
Возникали из-за опечаток во время написания программного кода. Что является следствием невыполнения запроса. |
5 |
|
Выбор поля в запрос, не соответствующий заданному запросу |
В результате чего вместо значений переменных в запрос передавались строковые параметры, имеющие значение, равное имени переменной. |
6 |
|
При работе со схемой данных не всегда удавалось задать связь таблиц |
Следствием является несоответствие имен полей или несоответствие типов данных связываемых полей. |
5 |
|
В подстановке из других таблиц |
Подстановка не производилась, т.к. не были настроены свойства подстановки. |
2 |
|
Вводимое значение в поле превышает допустимое |
Размер поля не соответствует введенному значению. |
2 |
Секpетаpская работа требует умения быстро переключаться с одного вида деятельности на другой и хаpактеpизуется широтой и pазнообpазием выполняемых функций. Важнейшая функция секpетаpя - оказание максимальной помощи руководителю и экономия его времени.
В процессе создания данного программного продукта были учтены все пожелания будущего пользователя - секретаря канцелярии Верховного Суда Республики Хакасия. Данный программный продукт позволяет секретарю канцелярии Верховного Суда Республики Хакасия быстро и удобно вычислять качество проведенных дел, быстро создавать отчеты, вести архив данных в базе данных о судьях и подсудимых. В дальнейшем данный программный продукт будет дополняться или изменяться по требованиям секретаря канцелярии Верховного Суда Республики Хакасия.
Предположительно, секретарю канцелярии ВС РХ в будущем могут понадобится такие функции как:
Выводы по показателям анализа качества:
1. Для определения уровня производительности и надежности системы была построена система показателей качества и выявлены основные направления проведения анализа.
2. В результате тестирования были выявлены ошибки, которые были устранены в короткие сроки.
3. Тестирование показало, что система готова к использованию, имеет хорошую надежность и на практике приемлемую производительность.
В ходе работы были реализованы следующие пункты, соответствующие поставленным задачам:
Важный аспект применения Delphi заключается в широком использовании технологии быстрой разработки приложений (Rapid Application Development, RAD). Это позволяет разрабатывать приложения в несколько раз быстрее более традиционных способов разработки. Например, при использовании традиционных методов программирования, создание графического интерфейса программы, включая обработку событий мыши, клавиатуры, включение в программу изображений и звука даже при использовании специальных API занимало довольно большую часть времени программиста и зачастую, программный код, отвечающий за интерфейс, занимал около 80-90% от общего кода программы.
Использование этого продукта обеспечивает единую среду разработки. Delphi – одна из самых мощных систем, позволяющих на самом современном уровне создавать как отдельные прикладные программы, так и разветвленные комплексы, предназначенные для работы в корпоративных сетях и в Internet. В качестве основного языка программирования в Delphi применяется Object Pascal. Это объектно-ориентированный язык программирования позволяющий организовать современный подход к построению программ и систем разного уровня сложности. Одним из методов решения стало появление концепции визуальных языков программирования, где разработка интерфейса приложений упрощалась за счет библиотеки стандартных элементов управления. Такая концепция была впервые реализована в языке Microsoft Visual Basic. Но компания Borland пошла гораздо дальше и расширила ее до RAD. Тем самым, внедрив возможность не только быстро строить из готовых элементов интерфейс приложения, но так же включать другие объекты, реализующие различные аспекты логики программы, например, объекты доступа к базам данных или взаимодействия с сетью.
Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.
MS Access – это качественная СУБД, которая приобрела довольно большую популярность во всем мире. Особенно, где дело касается разработки некоммерческих программных проектов по обработке данных.
Перечислим основные возможности MS Access:
|
№ п/п |
Понятие |
Определение |
|
1 |
2 |
3 |
|
1 |
Атрибут |
некоторый показатель, характеризующий объект и принимающий для каждого объекта индивидуальное значение. |
|
2 |
База данных |
это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области |
|
3 |
Жизненный цикл |
это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации |
|
4 |
Запрос |
обращение клиента к серверу с целью получения данных из базы данных. |
|
5 |
Индекс |
механизм, обеспечивающий быстрый доступ к строкам таблицы базы данных или организующий соблюдение ограничений целостности |
|
6 |
Интерфейс |
определенная стандартами или регламентированная граница между взаимодействующими независимыми объектами или системами |
|
7 |
Информация |
сведения об объекте или процессе, представленные в какой-либо знаковой (символьной) системе |
|
8 |
Информационная система |
взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации, необходимой в процессе принятия |
|
9 |
Компьютерные технологии |
средства и методы получения, обработки, хранения и передачи информации с использованием компьютерной техники |
|
10 |
Локальная сеть |
это множество компьютеров, соединенных друг с другом каналами связи, плюс набор стандартных правил, по которым они обмениваются информацией. |
|
11 |
Модель |
это упрощенное подобие реального объекта. Свойства модели определяются целью, ради которой она создается |
|
1 |
2 |
3 |
|
12 |
Модель данных |
совокупность структур данных, операций их обработки и ограничений целостности. |
|
13 |
Нормализация отношений |
формальный аппарат ограничений на формирование отношений (таблиц), позволяющий устранить дублирование, обеспечить непротиворечивость хранимых в базе данных |
|
14 |
Ограничения целостности |
механизм СУБД для контролирования значений, который могут храниться в полях строки таблицы базы данных |
|
15 |
Операционная система |
совокупность программных средств, для управления ресурсами ЭВМ, выделения и разделения ресурсов между программами и обеспечения интерфейса пользователя с ресурсами компьютера |
|
16 |
Платформа |
функциональный блок, интерфейс и сервис которого определяется стандартом, вводимым международной организацией или группой фирм |
|
17 |
Поле базы данных |
элементарная единица логической организации данных, которая соответствует неделимой единице информации |
|
18 |
Предметная область |
часть реального мира, подлежащего автоматизации в ходе ее изучения. |
|
19 |
Программное обеспечение |
совокупность программ для ЭВМ, обеспечивающее пользователя функциями, необходимыми для полноценного взаимодействия и использования ЭВМ. |
|
20 |
Реляционная модель данных |
модель данных, при которой любой набор данных можно представить в виде двумерной таблицы |
|
21 |
Сервер базы данных |
сервер сети, основная функция которого выделена для хранения и обслуживания баз данных (обработка, поддержка целостности, аутентификация). |
|
22 |
Система управления базой данных |
это программное обеспечение, позволяющее создавать БД, обновлять хранимую в ней информацию, следить за целостностью БД, обрабатывать информацию |
|
23 |
Таблица |
объект реляционной базы данных, представляющий собой двумерный массив и хранящий информацию в виде последовательности записей |
|
1 |
2 |
3 |
|
24 |
Язык программирования |
формальный язык для записи последовательности команд решения задачи, содержание и правила которого реализуются на компьютере. |
|
25 |
AdoQuery |
использует инструкции языка SQL для работы с таблицами через ADO и позволяет управлять этими данными через DataSource. |
|
26 |
DataSource |
Определяет источник данных чтобы получить текущие значения полей таблицы, чтобы их в последствии использовать в качестве параметров в SQL. |
|
27 |
SQL |
язык запросов баз данных и программирования. |
Список использованных источников
АРМ – автоматизированное рабочее место
БД – база данных
ЖЦ – жизненный цикл
ПП – программный продукт
ПС – программное средство
ВС РХ – Верховный Суд Республики Хакасия
СУБД – система управления базами данных
ЭВМ – электронная вычислительная машина
ADO – ActiveX Data Objects (Объекты данных ActiveX)
DFD – Data Flow Diagram (диаграммы потоков данных)
ERD – Entity-Relationship Diagram (диаграмма сущность-связь)
MS – Microsoft
RAD – Rapid Application Development (быстрая разработка приложений)
SADT – Structured Analysis and Design Technique (Технология структурного анализа и проектирования)
SQL – Structured Query Language (структурированный язык запросов)
Приложение A
«Схема работы секретаря с информацией после внедрения ПО»
Приложение Б
«Декомпозиция контекстной диаграммы обработки информации неавтоматизированным путем»
Приложение В
Сущностью «Подсудимые»
1Верников, Г.Н. Методология структурного анализа и проектирования SADT [Электронный ресурс] / Н.Г.Верников. - http://www.vernikov.ru/sadt_index.html.
2 Вендров, А.М. Методология функционального моделирования SADT [Электронный ресурс] / А.М.Вендров. - http://info-system.ru/designing.
3 Рассел, А. Модели жизненного цикла высокотехнологичных проектов [Электронный ресурс] / А. Рассел. - http://www.pmo.ru/models.php.
4 Международные стандарты, поддерживающие жизненный цикл программных средств [Текст]. - М., 2006. – С. 156.
5 Зиглер, К. Методы проектирования программных систем [Текст] / К.Зиглер. – М., 2008 – С.135.
6 Фленов, М.Е. Библия Delphi [Текст] / М.Е.Фленов – СПб., 2004. – С. 155.
7 Карпов, Б. Microsoft Access 2003: справочник [Текст] / Б.Карпов – М., 2006 – С. 187.
8 Паронджанов, С. Электронная методология и технология автоматизированного проектирования, разработки и сопровождения информационных систем [Электронный ресурс] / С.Паронджанов. - http:www.citforum.ru/programming/prg96/72.shtml.