В соответствии с учебным планом я проходил производственную практику в ООО «Ситиком» c 26 января 2016 года по 12 апреля 2016 года.
Я был принят для прохождения производственной практики в подразделение «Служба сервиса» на должность техника-программиста.
Совместно с руководителем практики был составлен план выполнения задания практики.
В процессе прохождения производственной практики я согласно задания практики ознакомился :
- С видами программирования и их спецификой;
- Разработкой и анализом требований к программной среде;
- Проектированием и кодированием ПО;
- Тестированием и сопровождением ПО;
- Инструментальными средствами разработки программ;
- Стандартами на документирование программных средств.
Выполнял функции техника-программиста:
- Участвовал в проектировании ПО;
- Участвовал в разработке ПО;
- Тестировал ПО;
- Разрабатывал программную документацию;
- Проводил техническое обслуживание ПЭВМ;
- Занимался поиском и устранением неисправностей ПЭВМ;
- Проводил диагностику ПЭВМ.
1 Технология разработки программного обеспечения
1.1 Изучение программного обеспечения предприятия
На предприятии ООО «Ситиком» используется следующее программное обеспечение:
- Операционные системы “Windows 7 Professional” и “Windows 7 Home Basic”.
- Текстовый редактор “Microsoft office 2007” используются всеми работниками для ведения документооборота;
- Программа для распознавания текста “ABBY Fine Reader 11” используется для перевода сканированных изображений в текстовый формат для последующего редактирования;
- Система управления базами данных “Microsoft SQL Server” используется для хранения баз данных “WordPress”;
- Система управления содержимым сайта “WordPress” используется для проведения обучения и тестирования слушателей. Администратором системы является программист;
- Интегрированная среда разработки программного обеспечения “Visual Studio 2013” используется для разработки приложений для решения задач организации.
1.2 Разработка и анализ требований к программной системе
Процесс работы с требованиями к продукту можно разделить на 4 этапа:
- Определение концепции продукта.
- Сбор требований.
- Анализ требований.
- Проектирование системы
Определение концепции продукта
Разработка информационного обеспечения электронного документооборота
... универсальные программы, способные удовлетворить потребности основной массы покупателей. Целью работы является создание информационной системы электронного документооборота масштаба организации. Данная система должна упростить документооборот, и ... Основные средства, нематериальные активы и материальные запасы 515 042 555 489 9 Требования по получению процентов 55 006 2 859 10 Прочие активы 861 ...
На этапе определения концепции продукта, проводится работа с его инвестором, целью которой является выработка единого видения будущего продукта. По окончанию этого этапа производится вывод о том, будет ли этот продукт разрабатываться или нет.
Сбор требований
Первый этап, с которого следует начинать разработку продукта — это сбор требований. Он может выполняться сразу и полностью (в рамках каскадного процесса) или же последовательно, по частям (в циклических и итерационных процессах).
На этапе сбора требований основная работа ведется с заказчиком системы и её будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы.
Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки.
Анализ требований
Сразу за сбором требований идет их анализ. Эти два процесса могут выполняться одним человеком последовательно или параллельно группой людей (Группа, занимающаяся сбором требований, передает их аналитикам, которые сразу анализируют полученные данные).
Продолжительность анализа требований, как правило, занимает в несколько раз меньше времени, чем сбор требований и в большей степени зависит от требований к документообороту, принятому в компании.
На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе.
Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет и не даст расползтись рамкам проекта.
Проектирование системы
Проектирование — процесс предшествующий разработке продукта. Для проектов, использующих итерационную/циклическую модель разработки, с самого начала должно производиться высокоуровневое проектирование системы — определение высокоуровневой архитектуры, а в начале каждой итерации должна происходить её детализация.
Целью всех предыдущих этапов был сбор информации о том, кому и зачем необходим будущий продукт. Этап проектирования — это первый этап, на котором группа разработки принимает проектные решения о том, какую функциональность будет нести продукт, чтобы удовлетворить пользователей.
Результатом этого этапа является законченное техническое задание к продукту. Оно должно содержать полное описание поведения будущего продукта и не содержать неоднозначностей и вопросов.
На основе технического задания начинается моделирование работы продукта с конечными пользователями (используя макеты пользовательского интерфейса, к примеру) и производится тестирование технического задания. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт.
Основные технические и эксплуатационные требования к системе ...
... вид станции управления движением судна. панель органов управления маневровой системы. Состав органов управления на панелях станции зависит от конфигурации движительно-рулевого комплекса судна ... и характера рыскания. Режимы управления движением но траектории. Суда, на которых устанавливаются ИСМ, снабжаются системой автоматической вождения судна по заданной траектории - САВТ (TrackControlSystem). ...
1.3 Проектирование программного обеспечения
Формирование детального описания будущего продукта — основная задача аналитика в процессе проектирования. Ранее, на этапах сбора и анализа определялись требования пользователей к системе — мотивы, по которым они будут её использовать. Теперь нужно определить, каким именно способом требования пользователей будут удовлетворены. Только с этого момента команда разработки продукта получает право принимать проектные решения — решать, какая конкретно функциональность будет реализована (Отвечать на вопрос — «что?»).
В процессе проектирования группой разработки продукта должно быть создано «Техническое задание» (Functional Specification), на основе которого будет производиться разработка и тестирование продукта. Это документ должен содержать следующие элементы:
- Требования к продукту уровня системы;
- Модель взаимодействия с пользователем;
- Диаграммы вариантов использования продукта;
- Потоки выполнения вариантов использования;
- Ограничения интерфейсов;
- GUI макеты;
- CLI/ API спецификации;
- Архитектура продукта;
- Техническая информация.
На основе хорошего технического задания может быть определен исчерпывающий список работ и определены сроки его реализации. Чем выше качество технического задания, тем ниже риски и выше качество конечного продукта.
Определение функциональных требований к продукту уровня системы
В основу функциональных требований следует взять список функций продукта, который был определен на этапе создания концепции. Этот список является поверхностным и, возможно, содержит неточности, поэтому первым делом нужно уменьшить список неверных предположений, подкрепив все имеющиеся предположения фактами. Для этого понадобится выполнить исследования и/или привлечь специалистов предметной области.
Далее нужно произвести детализацию требований, описав все, что следует реализовать для удовлетворения пользовательских требований.
При описании требований важно абстрагироваться от пользовательского интерфейса, так как иначе вы сильно ущемите в возможностях ваших дизайнеров при его проектировании.
Функциональные требования рекомендуется структурировать в виде дерева, в котором дочерние требования расширяют функционал родительского. Кроме этого, можно создать диаграмму вариантов использования, на которой отобразить все взаимозависимости в продукте — это сильно облегчит процесс проектирования системы и сведет к минимуму ошибки в нем.
Каждое функциональное требование должно иметь родительское пользовательское требование и учитывать все требования к дизайну. Приоритет требований должен быть унаследован от родительского требования с максимальным приоритетом.
Работа может считаться законченной, когда удовлетворены все цели, содержащиеся в пользовательских историях (текущей итерации).
Ключевой фигурой в определении функциональных требований должен быть ведущий разработчик или менеджер проекта. Также, по возможности, стоит привлекать специалистов предметной области и конечных разработчиков, которые будут реализовывать функционал. Аналитик должен следить, чтобы в процессе обсуждения функционала, пользовательские требования трактовались без искажений, а предлагаемый функционал полностью им отвечал.
Автоматизация учета готовой продукции
... экономическая сущность задачи Положением по БУ «Учет готовой продукции» определены следующие понятия: Готовая продукция (ГП) - это изделия, которые полностью ... объем продаж является основой разработки производственной программы. Предприятие должно производить только те товары ... справочники продукции, в которых содержится информация об облагаемой и необлагаемой различными видами налогов продукции, о ...
После того, как определен набор функций, который должен предоставлять продукт, нужно решить, каким образом пользователь сможет им воспользоваться. Для этого, на этапе создания диаграммы вариантов использования все функции продукта будут структурированы, и определен способ доступа к ним (прямой, расширение, включение).
Далее, на этапе описания потоков выполнения будет смоделировано поведение продукта при взаимодействии пользователя с большим количеством функций и подразумевающим нелинейную реакцию системы (как правило, реализуются при помощи мастеров).
В заключении должны быть определены непосредственные интерфейсы взаимодействия с системой;
— Как только список функций продукта определен, можно начинать работу по детализации архитектуры продукта, проводить исследования и назначать разработчикам задачи, не касающиеся пользовательского интерфейса.
1.4 Кодирование программного обеспечения
Кодирование программного обеспечения — собственно разработка программы или написание кода программы. Используемые технологии различны и у каждого специалиста в этой сфере есть свои предпочтения. На данном этапе осуществляется создание ПО с учетом выставленного технического задания.
Понятия кодирования и декодирования.
Использование электронно-вычислительных машин для переработки информации явилось коренным этапом в совершенствовании систем планирования и управления на всех уровнях народного хозяйства. Однако при этом, в отличие от обычных способов сбора и обработки информации, возникли проблемы преобразования информации в символы, понятные для машины. Неотъемлемым элементом этого процесса является кодирование информации. Кодом принято называть совокупность символов, соответствующих элементам информации или ее характеристикам. Сам процесс составления кода в виде совокупности символов или списка сокращений для соответствующих элементов и характеристик называется кодированием. Цель кодирования состоит в том, чтобы представить информацию в более компактной и удобной форме для оперирования при передаче и обработке информации ; приспособить кодированную информацию к обработке на вычислительных устройствах; обеспечить использование некоторого определенного метода поиска, сортировки и упорядочения информации.
В результате обработки информации получаются выходные коды, которые выдаются как результат проведенной обработки. Декодирование является операцией, обратной кодированию. Если при кодировании происходит преобразование информации в сигналы в виде определенного сочетания символов, соответствующих данному объекту или его характеристике, то при декодировании , наоборот, по заданному коду определяется соответствующий объект или его признаки. Например, в телефонном справочнике указан код, т.е. номер телефона , связанный с некоторым элементом (лицом или учреждением).
Операция декодирования состоит из набора кода номера телефона, который в виде сигналов поступает в АТС, где декодируется с помощью электрической схемы.
Процесс кодирования.
Процесс кодирования информации производится ручным способом с помощью ввода информации в ЭВМ в виде буквенно-цифрового текста на естественном языке. При кодировании требуется хранение в памяти ЭВМ словаря, в котором каждому слову соответствует определенный код. По этому словарю машина сама кодирует текст. При этом отпадает необходимость в классификации и кодировании информации по ее смысловому содержанию, так как кодируются сами слова, выражающие определенные характеристики предметов. Большое разнообразие технических характеристик и других данных, относящихся к производству и потреблению многочисленных видов продукции, не позволяет включить все необходимые данные для их производства в код продукции, так как этот код содержал бы большое число символов. Поэтому задача кодирования продукции заключается в том, чтобы иметь возможно более короткий код, по которому в памяти машины можно было бы найти подробную информацию о всех необходимых данных, относящихся к каждому изделию. Таким кодом является ключевой код.
Тестирование программных продуктов
... тестированию программ. Нашу классификацию различных форм тестирования мы начнем с того, что дадим эти определения, слегка их дополнив и расширив их список. Тестирование Доказательство Контроль Испытание Аттестация Отладка Тестирование модуля, ...
Для каждого ключевого кода в памяти ЭВМ должен храниться массив данных, которые извлекаются из памяти и используются для решения различных задач. Этот массив информации должен быть единым для всех решаемых задач, например каталогом продукции, где в одном месте хранятся все необходимые данные о каждом предмете. Разделение его на ряд отдельных массивов, записанных, например, на различных участках жесткого диска, нецелесообразно, так как это привело бы к повторению одной и той же информации и увеличению объема хранимой информации. Основное требование к ключевому коду — однозначный поиск ЭВМ признаков, относящихся к данному предмету, для которого ключевой код является адресом. Ключевой код может быть просто порядковым регистрационным номером и не нести какой-либо конкретной информации о продукции или, наоборот, может быть построен по определенной системе классификации и содержать конкретную информацию об основных признаках продукции, вполне ее определяющих. Второй способ кодирования более эффективен, так как регистрационный код не дает возможности осуществить предварительную сортировку информации по ее содержанию. Ключевой код позволяет производить сортировку карточек продукции по главным определяющим признакам. Детальная спецификация и ее остальные характеристики находятся в предварительно отсортированных карточках.
Исходный код программы подлежит трансляции, в ходе которой выполняется синтаксический разбор инструкций программы, исходный код программы преобразуется в объектный код (object file).
В зависимости от способа анализа синтаксиса программ и построения объектного кода различают:
- компиляторы — осуществляющие полный разбор программного кода с последующим выполнением объектного кода программы;
- интерпретаторы — контролирующие каждую отдельную инструкцию и немедленно ее выполняющие.
Сборка программы состоит в преобразовании объектного файла и подключаемых библиотек процедур и объектов, разрешении перекрестных ссылок между программными модулями. В результате формируется исполнимый код программы, который представляется в виде файла с расширением .EXE или .COM или создается программный модуль, запускаемый в среде реализации приложения (задачи).
1.5 Тестирование и сопровождение программного обеспечения
«Тестирование — процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет.» Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Правильное определение тестирования таково: Тестирование — процесс выполнения программы с намерением найти ошибки.
Автоматизация тестирования программного обеспечения
... (OR, AND). 3 . Функциональное тестирование 3.1 Выбор метода тестирования Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, ...
Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами.
Тестирование оказывается довольно необычным процессом (вот почему оно и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего— заставить программу сбиться. Он доволен, если это ему удается; если же программа на его тесте не сбивается, он не удовлетворен.
В тестировании можно выделить несколько различных процессов, такие термины, как тестирование, отладка, доказательство, контроль и испытание, часто используются как синонимы и для разных людей имеют разный смысл. Стандартные, общепринятые определения:
Тестирование (testing), — процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы.
Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.
Аттестация (certification) — авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы извесной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.
Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей).
Тестирование модуля иногда включает также математическое доказательство.
Тестирование сопряжений (integration testing) — контроль сопряжении между частями системы (модулями, компонентами, подcистемами).
Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями.
Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
Разработка программного модуля
... программы управлять ее работой и получать требуемые результаты, т.е. это диалог между компьютером и пользователем. Интерфейс для программного модуля, разработанного в данном курсовом ... программного модуля» описан код программы, произведено описание используемых операторов и функций. Тестирование программного модуля ... главную диагональ. 2.2 Разработка схемы программного модуля и ее описание ...
Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.
Тестирование настройки (installation testing) — проверка соотетствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
Интеграция модулей.
Вторым по важности аспектом тестирования (после проектирования тестов) является последовательность слияния всех модулей в систему или программу. Эта сторона вопроса обычно не получает достаточного внимания и часто рассматривается слишком поздно. Выбор этой последовательности, однако, является одним из самых жизненно важных решении, принимаемых на этапе тестирования, поскольку он определяет форму, в которой записываются тесты, типы необходимых инструментов тестирования, последовательность программирования модулей, а также тщательность и экономичность всего этапа тестирования. По этой причине такое решение должно приниматься на уровне проекта в целом и на достаточно ранней его стадии.
Имеется большой выбор возможных подходов, которые могут быть использованы для слияния модулей в более крупные единицы. В большинстве своем они могут рассматриваться как варианты шести основных подходов, описанных в следующих шести разделах. Сразу же за ними идет раздел, где предложенные подходы сравниваются по их влиянию на надежность программного обеспечения.
Восходящее тестирование.
При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня («терминальные» модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжении программы.
При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решении — написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей — это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы.
Нисходящее тестирование.
Нисходящее тестирование (называемое также нисходящей разработкой не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое, При нисходящем подходе программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются (например, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули.
Разработка автоматизированной системы управления с разработкой ...
... Целью дипломной работы является разработка автоматизированной системы управления с разработкой программного средства учёта выполнения заказов для организации работы ООО «Редтех». Необходимостью разработки такой автоматизированной системы управления послужило то, что используемые в работе организации способы и средства хранения и обработки ...
Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство — в том, что этот метод совмещает тестирование модуля, тестирование сопряжении и частично тестирование внешних функций. С этим же связано другое его достоинство — когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программы в целом или если в проекте программы могут оказаться серьезные дефекты.
Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки».
Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является тот, что модуль редко тестируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потребовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить тестирование рассматриваемого модуля позже, когда уберет заглушки. Такой план тестирования определенно не лучшее решение, поскольку об отложенных условиях часто забывают.
Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. Большинство опытных проектировщиков признает, что проектирование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэкономить больше, чем те несколько дней или недель, которые рассчитывает выиграть проектировщик, приступая к программированию слишком рано.
Модифицированный нисходящий метод
Нисходящий подход имеет еще один существенный недостаток, касающийся полноты тестирования. Предположим, что есть большая программа и где-то ближе к нижнему ее уровню находится модуль, предназначенный для вычисления корней квадратного уравнения. Для заданных входных переменных А, В и С он решает уравнение .
При проектировании и программировании модуля с такой функцией всегда следует понимать, что квадратное уравнение может иметь как действительные, так и комплексные корни. Для полной реализации этой функции необходимо, чтобы результаты могли быть действительными или комплексными числами (или, если дополнительные затраты на нахождение комплексных корней не оправданы, модуль должен по крайней мере возвращать код ошибки в случае, когда входные коэффициенты задают уравнение с комплексными корнями).
Жизненный цикл информационных систем
... - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов. Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую ...
Предположим, что конкретный контекст, в котором используется модуль, исключает комплексные корни (т. е. вызывающие модули никогда не задают входных параметров, которые привели бы к комплексным корням).
При строго нисходящем методе иногда бывает невозможно тестировать модуль для случая комплексных корней (или тестировать ошибочные условия).
Можно попытаться оправдывать это тем, что, поскольку такое уравнение никогда не будет дано модулю, никого не должно заботить, работает ли он и в этих случаях. Да, это безразлично сейчас, но окажется важным в будущем, когда кто-то попытается использовать модуль в новой программе или модифицировать старую программу так, что станут возможными и комплексные корни.
Эта проблема проявляется в разнообразных формах. Применяя нисходящее тестирование в точном соответствии с предыдущим разделом, часто невозможно тестировать определенные логические условия, например ошибочные ситуации или защитные проверки. Нисходящий метод, кроме того, делает сложной или вообще невозможной проверку исключительных ситуаций в некотором модуле, если программа работает с ним лишь в ограниченном контексте (это означает, что модуль никогда не получит достаточно полный набор входных значений).
Даже если тестирование такой ситуации в принципе осуществимо, часто бывает трудно определить, какие именно нужны тесты, если они вводятся в точке программы, удаленной от места проверки соответствующего условия.
Метод, называемый модифицированным нисходящим подходом, решает эти проблемы: требуется, чтобы каждый модуль прошел автономное тестирование перед подключением к программе. Хотя это действительно решает все перечисленные проблемы, здесь требуются и драйверы, и заглушки для каждого модуля.
Метод большого скачка.
Вероятно, самый распространенный подход к интеграции модулей — метод «большого скачка». В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу.
Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств. Заглушки и драйверы необходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Метод большого скачка значительно усложняет отладку.
И все же большой скачок не всегда нежелателен. Если программа мала и хорошо спроектирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен.
Бета — тестирование программного обеспечения.
Другой способ проверки, — бета-тестирование. В этом случае разработчики программного обеспечения разрешают пользователям попробовать предварительные версии продуктов.
Качественный и эффективный результат можно гарантировать лишь только при ответственном и детальном исполнение каждого из приведенных этапов.
1.6 Коллективная разработка программного обеспечения
Преобладающим методом коллективной разработки является организация бригад. Метод предметных связей используется реже, тогда когда ведется разработка не тиражируемого продукта силами организации, которая будет и вести его эксплуатацию.
С административной точки зрения, бригада — структурная производственная единица, которая может быть образована в рамках существующего структурного подразделения для выполнения определенной работы, имеющей конкретный результат.
При определении результата работы бригады может быть сформулировано частичное техническое задание.
Существуют два варианта бригад:
- предметная область определяется в терминах программирования, то есть задание представляется собой результат работы относящийся к программированию;
- предметная область определяется в терминах того языка, который используется в предметной области (функционально и математическо ориентированные программные продукты);
— В первом случае предметная область имеет вид хорошо знакомый и понятный программисту и работа предполагает техническое проектирование может выполнить программист. Бригада может быть сформирована из специалистов одного профиля (в основном программисты).
Во втором случае работы по техническому проектированию могут быть выполнены специалистом в предметной области. Принятое им проектное решение, вплоть до технического проекта в дальнейшем доводится до машинной реализации специалистом-программистом, параллельно эксплуатируется документация, по возможности, должна разрабатываться специалистом из предметной области. В процессе внедрения, проверка работоспособности программного продукта тоже проводится специалистом из предметной области.
Формирование специализированных бригад (из специалистов одного профиля).
Результат работы отдельной бригады не всегда представляет собой конечный результат разработки.
Сложнее вести управление разработкой, требуется строгая формализация работ каждой бригады. На поздних этапах разработки результаты могут отклоняться от ТЗ.
Если из-за сложности и масштабности разработки требуется большое число исполнителей и организация нескольких бригад, то рекомендуется:
- Рассмотреть вопрос о специализации бригад по функциональному признаку;
- Желательно выделить ведущую, главную бригаду.
Эта бригада выполняет наиболее существенное задание и как можно больше участвует в жизненном цикле. Бригаде даются другие бригады соисполнители (которые могут быть со своим ТЗ).
Выявляются функции управления, подлежащие автоматизации, или те по которым пересматриваются ранее действующие решения. Решаются задачи методами иерархической декомпозиции: разбиения некоторой сложной проблемы функции управления на ряд ее частных составляющих (под проблем), до тех пор, пока по каждой составляющей полученной на очередном шаге не будет детально определены информационные входы и выходы.
После того как определились с взаимосвязью отдельных задач, проводится обследование информационной схемы решаемых задач. Сначала выходная информация (пожелания заказчика), входная информация (оперативная, нормативно-справочная) и процесс-метод реализации перехода от входа к выходу.
2 Использование инструментальных средств разработки программного обеспечения
2.1 Изучение инструментальных средств разработки программ предприятия
При разработке программного продукта задействуется довольно большой спектр инструментального ПО, которое решает некоторые специальные задачи. Довольно условно их можно разбить на четыре группы:
1. необходимые — те, без которых невозможно в принципе получить исполняемый код;
К необходимым можно отнести:
- редакторы текстов;
- компиляторы и ассемблеры;
- компоновщики или редакторы связей (linkers);
2. часто используемые — средства, использования которых, в отличие от необходимых, можно избежать. Но без них процесс разработки весьма затрудняется и удлиняется;
Из часто используемых средств стоит назвать:
- утилиты автоматической сборки проекта;
- отладчики;
- программы создания инсталляторов;
- редакторы ресурсов;
- профилировщики;
- программы поддержки версий;
- программы создания файлов помощи (документации).
3. специализированные — используются в исключительных случаях, решают довольно специфичные задачи:
- программы отслеживания зависимостей;
- дизассемблеры;
- декомпиляторы;
- hex-редакторы;
- программы отслеживания активности системы и изменений, происходящих в системе;
- программы-вериферы и контейнеры (создают виртуальную среду для отдельных классов программ, в которой можно исследовать поведение программы)
и т.д.;
- Интегрированные среды — содержат большую часть из приведенных выше программ и позволяют упростить процесс создания приложений.
В каждом классе существуют огромное число продуктов, каждый со своими особенностями, достоинствами и недостатками.
В организации ООО «Ситиком» используется интегрированная среда “Visual Studio 2013”.
2.2 Работа с Case — технологиями предприятия
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Visual Studio — это интегрированная среда разработки (IDE) от Microsoft, основной инструмент разработки приложений для платформы .NET и Windows в целом. В ней можно разрабатывать приложения на языках C#, VB.NET, F# и C++/CLI. Также доступны дополнения, позволяющие программировать в Visual Studio на языках Python, Ruby и других.
Средства Visual Studio для создания приложений Windows Forms.
Создание графического интерфейса пользователя (GUI) с помощью технологии Windows Forms является одним из самых простых способов быстрой разработки приложения, не только благодаря простой объектной модели, но и обширной поддержке Windows Forms в Visual Studio. Среда предлагает множество средств, одним из самых удобных и широко используемых является визуальный конструктор, в котором можно создавать и настраивать GUI, воочию при этом наблюдая конечный результат этого процесса.
Создание проекта нового приложения Windows Forms.
Начало работы с Windows Forms начинается с создания нового проекта, который создаётся, как и любой другой проект, из окна «Создать проект» (ФАЙЛ — Создать — Проект…, Ctrl+Shift+N).
Среди установленных шаблонов нужно выбрать «Приложение Windows Forms».
Вновь созданный проект содержит минимальный набор файлов, каждый из которых имеет своё назначение:
MainForm.cs — (может называться Form1.cs или любым другим корректным именем Windows) один из наиболее важных файлов, который содержит логику работы приложения. В нём размещаются вновь созданные обработчики событий, описываются свойства и поля, реализуются пользовательские методы или переопределяются методы родительского класса (System.Windows.Forms.Form).
Визуальный конструктор формы открывается именно из этого файла.
MainForm.Designer.cs — этот файл содержит код, автоматически генерированный визуальным конструктором при добавлении элементов управления на форму и изменения их свойств. В подавляющем большинстве случаев, вам не придётся беспокоиться о содержимом этого файла и, тем более, исправлять его.
Resources.resx, MainForm.resx и др. — файлы ресурсов, первый из них содержит ресурсы для всего приложения, MainForm.resx и все другие с именем, начинающимся с имени формы содержат ресурсы для конкретной формы. Ресурсы могут включать в себя изображения, аудио- и видеофайлы, текст с возможностью локализации и т.д.
Program.cs — содержит точку входа приложения. Также редко подвергается изменению со стороны пользователя.
Визуальный конструктор.
В визуальном конструкторе, можно изменять внешний вид формы и пользовательских элементов управления, а также добавлять и удалять их без написания кода. В начальном виде, конструктор выглядит как вкладка, на которой расположена пустая форма.
Если в данный момент в среде открыта вкладка с кодом, можно быстро перейти к конструктору с помощью сочетания клавиш Shift+F7. Возврат к редактированию кода осуществляется клавишей F7.
Из «Панели элементов» можно перетягивать элементы управления на форму. Например, чтобы добавить кнопку, зажимаем левую кнопку мыши на элементе Button и перетягиваем её на нужное место на форме. Также допускается упрощённый вариант размещения — достаточно один раз кликнуть на элементе Button (не зажимать) и когда курсор окажется над формой, он изменит свой вид и, кликнув ещё раз, вы разместите элемент управления на форме.
Управление размерами и размещением, схоже с таковым в любом графическом редакторе — по краям элемента расположены полозки, потянув за которые можно изменить размер элемента. Когда курсор принимает вид крестика, элемент можно перемещать.
Теперь, когда основные понятия о конструкторе изложены, пришло время рассмотреть несколько основных сочетаний клавиш, действий и их эффектов, которые действуют одинаково почти для любого типа элемента управления:
Однократное нажатие левой кнопки мыши, показывает возможности для редактирования элемента — в панели «Свойства» отображаются настройки для конкретного типа элементов, а на границе появляются полозки изменения размеров и, иногда, кнопка с дополнительными действиями (чёрный треугольник).
Двукратное нажатие левой кнопкой мыши создаёт метод-обработчик события. У каждого из элементов управления по нескольку десятков событий, но Visual Studio создаёт обработчик только для часто используемого, характерного для данного элемента события. Например, для кнопки (Button) создаётся обработчик события Click (щелчок левой кнопкой мыши), а для флажка (CheckBox) — события CheckedChanged (изменения состояния отмечен/не отмечен).
Нажатие левой кнопки мыши по нескольким элементам с зажатой клавишей Ctrl позволяет выделить несколько элементов и перемещать их одновременно, сохраняя из взаимное положение. При выделении нескольких элементов, на панели инструментов становятся активными кнопки положения. С их помощью можно регулировать взаимное положение элементов управления и положение относительно родительского контейнера, например — выровнять центры по горизонтали или расположить по левому краю. Все эти команды также содержатся в меню ФОРМАТ.
Часто применяемые панели при работе с Windows Forms.
При конструировании графического интерфейса чаще всего мы будем пользоваться 3 панелями — это «Панель элементов», «Свойства» и «Структура документа». О первой уже было сказано выше, опишем оставшиеся две.
Панель «Свойства» (ВИД — Окно свойств, F4) содержит основные настройки выбранного в данный момент элемента. Конкретные значения можно вписывать как вручную, так и выбирать из списка (для свойств со специальным типом — цвет, шрифт и т.д.).
Справа от имени каждого события указано имя обработчика, если таковой имеется. Чтобы создать отладчик, дважды щёлкните по графе с именем события или впишите нужное вам имя — обработчик автоматически создастся и присоединится к событию.
Панель «Структура документа» (ВИД — Другие окна — Структура документа, Ctrl+Alt+T) отражает все добавленные на форму элементы управления и их взаимоотношения — какой является родительским, а какой — дочерним. Очень удобная возможность при работе с проектами, имеющими сложный интерфейс с обилием контейнеров.
Теперь используем самый быстрый способ сборки программы и ее запуска — нажмем в основном меню Start (он помечен жирной зеленой стрелкой вправо).
3. Документирование и сертификация
3.1 Стандарты на организацию жизненного цикла ПО
Стандарты жизненного цикла
Чтобы получить представление о возможной структуре жизненного цикла ПО, обратимся сначала к соответствующим стандартам, описывающим технологические процессы. программный обслуживание вычислительный
Группа стандартов ISO:
- ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes ( процессы жизненного цикла ПО, есть его российский аналог ГОСТ Р-1999).
Определяет общую структуру жизненного цикла ПО в виде 3 ступенчатой модели, состоящей из процессов, видов деятельности и задач. Стандарт описывает вводимые элементы в терминах их целей и результатов, тем самым задавая неявно возможные взаимосвязи между ними, но не определяя четко структуру этих связей, возможную организацию элементов в рамках проекта и метрики, по которым можно было бы отслеживать ход работ и их результативность.
- ISO/IEC 15288 Standard for Systems Engineering — System Life Cycle Processes ( процессы жизненного цикла систем).
Отличается от предыдущего нацеленностью на рассмотрение программно-аппаратных систем в целом.
— ISO/IEC 15288 предлагает похожую схему рассмотрения жизненного цикла системы в виде набора процессов. Каждый процесс описывается набором его результатов (outcomes), которые достигаются при помощи различных видов деятельности. Всего выделено 26 процессов, объединяемых в 5 групп.
- ISO/IEC 15504 (SPICE) Standard for Information Technology — Software Process Assessment (оценка процессов разработки и поддержки ПО).
Определяет правила оценки процессов жизненного цикла ПО и их возможностей, опирается на модель CMMI (см. ниже) и больше ориентирован на оценку процессов и возможностей их улучшения.
Группа стандартов IEEE:
IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes (стандарт на создание процессов жизненного цикла ПО).
Нацелен на описание того, как создать специализированный процесс разработки в рамках конкретного проекта. Описывает ограничения, которым должен удовлетворять любой такой процесс, и, в частности, общую структуру процесса разработки. В рамках этой структуры определяет основные виды деятельностей, выполняемых в этих процессах, и документы, требующиеся на входе и возникающие на выходе этих деятельностей. Всего рассматриваются 5 подпроцессов, 17 групп деятельностей и 65 видов деятельности.
- IEEE/EIA 12207-1997 — IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Software Life Cycle Processes [9,10,11] (промышленное использование стандарта ISO/IEC 12207 на процессы жизненного цикла ПО).
Аналог ISO/IEC 12207, сменил ранее использовавшиеся стандарты J-Std-016-1995 EIA/IEEE Interim Standard for Information Technology — Software Life Cycle Processes — Software Development Acquirer-Supplier Agreement (промежуточный стандарт на процессы жизненного цикла ПО и соглашения между поставщиком и заказчиком ПО) и стандарт министерства обороны США MIL-STD-498.
Группа стандартов CMM, разработанных SEI:
Модель зрелости возможностей CMM (Capability Maturity Model) предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня. Для этого определяются 3 уровня элементов: уровни зрелости организации (maturity levels), ключевые области процесса (key process areas) и ключевые практики (key practices).
Чаще всего под моделью CMM имеют в виду модель уровней зрелости. В настоящий момент CMM считается устаревающей и сменяется моделью CMMI (см. ниже).
Интегрированная модель зрелости возможностей CMMI (Capability Maturity Model Integration).
Эта модель представляет собой результат интеграции моделей CMM для продуктов и процессов, а также для разработки ПО и разработки программно-аппаратных систем.
Основные изменения по сравнению с CMM следующие.
Элементы модели получили четкие пометки о том, являются ли они обязательными (required), рекомендуемыми (expected) или информативными (informative).
Используемые практики разделяются на общие (generic) и специфические (specific).
Они дополняются набором общих и специфических целей, которые необходимы для достижения определенного уровня зрелости в определенных областях процесса.
Некоторые уровни зрелости получили другие названия. Второй уровень назван управляемым (managed), а четвертый — управляемым на основе метрик (quantitatively managed).
Набор выделяемых областей процесса и практик значительно изменился.
Управление процессом.
Включает выработку и поддержку процесса, контроль соблюдения процесса, обучение, измерение показателей процесса, внедрение инноваций.
Управление проектом.
Включает планирование проектов, контроль хода проекта, управление соглашениями с поставщиками, интегрированное управление проектами, управление рисками, построение команд, управление поставщиками и измерение показателей результативности и хода проекта.
Технические.
Включают выработку требований, управление требованиями, выработку технических решений, интеграцию продуктов, верификацию и валидацию.
Поддерживающие.
Включают управление конфигурацией, обеспечение качества продуктов и процессов, проведение измерений и анализ их результатов, управление окружением, анализ и принятие решений, анализ, разрешение и предотвращение проблем.
В целом перечисленные стандарты связаны так, как показано на рисунке 7, (сплошные стрелки указывают направления исторического развития, жирная стрелка обозначает идентичность, пунктирные стрелки показывают влияние одних стандартов на другие).
Рисунок 7 — Стандарты, описывающие структуру жизненного цикла ПО
Все рассмотренные стандарты определяют некоторый набор видов деятельности, из которых должен состоять процесс разработки, и задают ту или иную структуру на этих видах деятельности, выделяя их элементы. Вместе с тем, как можно заметить, они не могут быть сведены без существенных изменений в единую модель жизненного цикла ПО. В целом имеющиеся стандарты слабо согласованы между собой. Так что на сегодняшний день нет согласованного комплекта стандартов, покрывающего всю данную область, и в ближайшие несколько лет он вряд ли появится, хотя работа по согласованию различных стандартов ведется.
3.2 Стандарты на документирование программных средств
Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы: что должно быть сделано, кроме собственно программы? что и как должно быть оформлено в виде документации? что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом?
Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование?
На эти и массу других вопросов когда-то отвечали государственные стандарты на программную документацию — комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось — неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.
Общая характеристика состояния
Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД).
Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС.
Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС. Дело в том, что в соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПС.
