1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения
|
Скачать 198 Kb.
|
|
Содержание 1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения 2 Этап постановки задачи 2.1 Основное содержание этапа постановки задачи 2.2 Предпроектные исследования предметной области 2.3 Принципиальные решения начальных этапов разработки 3 Этап анализа требований и определения спецификаций 3.1 Спецификации и их классификация 3.2 Модели этапа анализа требований и определения спецификаций, не зависящие от подхода к разработке 3.3 Модели этапа анализа требований и определения спецификаций при структурном подходе 3.4 Модели этапа анализа требований и определения спецификаций при объектном подходе 4 Типовое содержание основной части отчета 1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения Основной целью преддипломной практики и последующего дипломного проектирования по специальности 230105 «Программное обеспечение вычислительной техники и автоматизированных систем» и направления подготовки бакалавров 230100.62 «Информатика и вычислительная техника»??? является получение практических навыков разработки и документирования программного обеспечения на учебной задаче. Поэтому, во-первых, необходимо рассмотреть процесс разработки программного обеспечения и охарактеризовать его этапы. В общем виде процесс разработки программного обеспечения можно представить схемой, приведенной на рисунке Х.1. Рисунок Х.1 – Схема процесса разработки программного обеспечения В настоящее время на практике применяются более эффективные модели жизненного цикла программного обеспечения, такие как модель с промежуточным контролем, каскадная модель, но для целей рассмотрения сущности основных этапов достаточно приведенной классической каскадной схемы. Кратко охарактеризуем приведенные на рисунке Х.1 этапы.
В рамках преддипломной практики основные внимание уделяется решению задач первых двух этапов. Во-первых, это соответствует назначению данного вида практики, как подготовительного этапа к дипломному проектированию. Во-вторых, как будет сказано ниже, на этих двух этапах исключительно важно активное взаимодействие между разработчиком программного обеспечения и представителями заказчика, каковым в данном виде учебной нагрузки выступает предприятие – база прохождения практики. 2 Этап постановки задачи Как было сказано выше, на данном этапе должны быть сформулированы основные требования к программному обеспечению. Каждое требование представляет собой описание необходимого или желаемого свойства программного обеспечения. Различают функциональные требования, определяющие функции, которые должно выполнять разрабатываемое программное обеспечение, и эксплуатационные требования, определяющие особенности его функционирования. 2.1 Основное содержание этапа постановки задачи На практике данный этап соответствует стадии «Техническое задание» в соответствии с ГОСТ 19.102-77 «Стадии разработки» и заканчивается разработкой технического задания на разработку программного продукта. В ходе преддипломной практики разработка такого документа не является обязательной, но содержание основных разделов технического задания тем или иным образом будет содержаться в отчете. Рассмотрим основные принципы разработки технического задания. В его основе лежат начальные требования заказчика (обычно неформализованные, неточные и непригодные для дальнейшей работы без преломления под углом взгляда разработчика). Поэтому при его подготовке необходимо активное взаимодействие разработчиков с заказчиком. Во-первых, должны быть получены следующие сведения:
На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Рассмотрим те разделы, содержание которых должно обязательно войти в материал отчета по преддипломной практике. 1. Раздел «Введение» должен содержать наименование и краткую характеристику области применения программного продукта, а также объекта (например, системы) в котором предполагается их использовать. Основное назначение введения – продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных. 2. Раздел «Назначение разработки» должен содержать описание функционального и эксплуатационного назначения программного продукта с указанием категорий пользователей. 3. Раздел «Требования к программе или программному изделию» включает в себя несколько подразделов. Наиболее важные из них: – требования к функциональным характеристикам; – требования к составу и параметрам технических средств; – требования к информационной и программной совместимости; Основным является подраздел «Требования к функциональным характеристикам». Именно в нем определяются функциональные требования к программному обеспечению, которые при сдаче-приемке будут проверяться в первую очередь. В этом разделе должны быть:
В этом же разделе при необходимости указывают критерии эффективности: максимально допустимое время реакции системы, максимальный объем используемой оперативной и/или внешней памяти и др. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик: тип микропроцессора, объем памяти, наличие внешних устройств и т.п. При этом часто указывают два варианта конфигурации: минимальный и рекомендуемый. В подразделе «Требования к информационной и программной совместимости» при необходимости можно определить язык или среду программирования для разработки, а также используемую операционную систему и другие системные и пользовательские программные средства, с которым должно взаимодействовать разрабатываемое программное обеспечение. В этом же разделе при необходимости указывают, какую степень защиты информации необходимо предусмотреть. 2.2 Предпроектные исследования предметной области Для разработки технического задания может потребоваться проведение предпроектных исследований предметной области. Их целью является формулирование более точных требований к программному обеспечению в условиях нечетких начальных представлений о решаемых задачах. Можно выделить два вида неопределенности, на устранение которых могут быть направлены предпроектные исследования:
В первом случае предпроектные исследования осуществляются с целью определить:
Во втором случае определяют:
В ходе преддипломного проектирования неопределенность первого вида возникает обычно только в случае специфических исследовательских тем дипломных работ. В отличие от процесса разработки технического задания, в ходе преддипломной практики предпроектные исследования являются обязательными. Также в большинстве тем преддипломной практики обязательным является анализ возможных методов решения задачи и существующих аналогов программных средств, реализующих подобные функции. Анализ аналогов преследует цели выявления эффективных способ реализации для их дальнейшего использования и недостатков существующих программных средств для их исключения в разрабатываемом программном обеспечении. 2.3 Принципиальные решения начальных этапов разработки Также на этапе постановки задачи должны быть приняты некоторые решения, принципиально влияющие как на этап анализа требований и определения спецификаций, так и на последующие этапы процесса разработки. К таким решениям относят:
Выбор архитектуры программного обеспечения. Архитектурой программного обеспечения называют совокупность базовых принципов его построения. Она определяется сложностью решаемых задач, степенью универсальности разрабатываемого программного обеспечения и числом пользователей, одновременно работающих с одной его копией. Различают:
Кроме того, в рамках однопользовательской архитектуры различают:
Многопользовательскую архитектуру реализуют системы, построенные по принципу «клиент-сервер». Выбор типа пользовательского интерфейса. Различают четыре типа пользовательских интерфейсов:
Выбор двух последних типов интерфейсов предполагает использование одной из визуальных сред разработки программного обеспечения. Если соответствующие среды разработчику не доступны, то следует учитывать большую трудоемкость создания подобных интерфейсов. Кроме того, выбор типа интерфейса включает выбор технологии работы с документами. Различают две технологии:
Многодокументную технологию используют, если программное обеспечение должно поддерживать работу с несколькими документами одновременно. Выбор подхода к разработке. На данный момент существует два основных подхода к разработке: структурный и объектный. Несмотря на то, что структурный подход был предложен намного раньше объектного, его применение является обоснованным для многих программных продуктов, особенно когда речь идет об учебном проекте, реализуемом в ходе дипломного проектирования. Практика показывает, что применение структурного подхода возможно и эффективно в случае программных систем сложностью до 100000 операторов. Применения объектного подхода может быть обосновано при разработке программных систем большой сложности (что невозможно в рамках дипломной работы), при ярко выраженной объектной структуре предметной области, а также в случае реализации интерфейсов со свободной навигацией или прямого манипулирования. Также на выбор подхода к разработке следует учитывать требования к эффективности программного обеспечения, так как применение технологии объектно-ориентированного программирования значительно повышаются требования программного обеспечения к ресурсу процессорного времени. Выбор языка и среды программирования. Языки, применение которых может потребоваться при разработке, можно разделить на группы:
В большинстве случаев язык программирования, используемый при реализации, предопределен:
Если выбор возможен, то следует обращать внимание на соответствие возможностей и сложности языка программирования конкретной задаче. Выбор языка почти полностью определяет выбор среды программирования. В случае возможности использования сред программирования различных производителей, основанных на одном и том же языке, также следует учитывать специфику решаемой задачи. 3 Этап анализа требований и определения спецификаций 3.1 Спецификации и их классификация Для получения спецификаций выполняют анализ требований, полученных на предыдущем этапе, формулируют содержательную постановку задачи, выбирают математический аппарат формализации, строят модель предметной области, определяют подзадачи и выбирают или разрабатывают методы их решения. Спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого программного обеспечения. При этом одна часть спецификаций (функциональные) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные) определяет требования к техническим средствам, надежности, информационной безопасности и т.д. В процессе разработки спецификаций должно осуществляться активное взаимодействие разработчиков, не являющихся обычно специалистами в предметной области, с заказчиком, направленное на получение как можно более точных и полных спецификации. Это требование исключительно важно, так как исправление ошибок, допущенных в процессе определения спецификаций, на более поздних этапах приводит к наиболее существенным затратам временных и трудовых ресурсов. Формальные модели, используемые на этапе определения спецификаций можно разделить на две группы: модели, зависящие от подхода к разработке (структурного или объектного), и модели, не зависящее от него. 3.2 Модели этапа анализа требований и определения спецификаций, не зависящие от подхода к разработке К независящим от подхода к разработке относятся:
Диаграммы переходов состояний. На этапе анализа требований и определения спецификаций диаграмма переходов состояний демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий. Под управляющими воздействиями или сигналами в данном случае понимают управляющую информацию, получаемую системой извне. Получив такое управляющее воздействие, разрабатываемая система должна выполнить определенные действия и или остаться в том же состоянии, или перейти в другое состояние взаимодействия с внешней средой. Несмотря на то, что традиционно диаграммы переходов состояний относятся к классу независящих от подхода к разработке, на данный момент они обычно используются только при структурном подходе. Математические модели предметной области. Для многих задач, которые часто встречаются на практике, в математике определены как модели, так и методы решения. Для задач, алгоритм решения которых не очевиден, используют разного рода математические модели. Процесс построения модели включает:
В рамках преддипломной практики необходимость разработка таких моделей возникает обычно только в случае исследовательских тем. 3.3 Модели этапа анализа требований и определения спецификаций при структурном подходе В рамках структурного подхода на этапе анализа и определения спецификаций используют три типа моделей: ориентированные на функции, ориентированные на данные и ориентированные на потоки данных. Все функциональные спецификации описывают одни и те же характеристики разрабатываемого программного обеспечения: перечень функций и состав обрабатываемых данных. Они различаются только системой приоритетов (акцентов), которая используется разработчиком в процессе анализа требований и определения спецификаций. Поскольку разные модели описывают проектируемое программное обеспечение с разных сторон, рекомендуется использовать сразу несколько моделей и сопровождать их текстами: словарями, описаниями и т. п., которые поясняют соответствующие диаграммы. Методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей:
Функциональные диаграммы. Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого программного обеспечения. Например, активностная модель методологии SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования), или более новая нотация IDEF0, реализованная в CASE-средствах. Диаграммы потоков данных. Диаграммы потоков данных позволяют специфицировать как функции разрабатываемого программного обеспечения, так и обрабатываемые им данные. При использовании этой модели систему представляют в виде иерархии диаграмм потоков данных, описывающих асинхронный процесс преобразования информации с момента ввода в систему до выдачи пользователю. На каждом следующем уровне иерархий происходит уточнение процессов, пока очередной процесс не будет признан элементарным. Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна-Сарсона. Основным отличием диаграмм потоков данных от функциональных диаграмм является четкое выявление внешних сущностей – источников и приемников информации и так называемых хранилищ данных – абстрактных устройств хранения информации. Также при использовании диаграмм потоков данных возможно более детальное моделирование процесса управления с помощью управляющих процессов, управляющих потоков данных и, возможно, хранилищ управляющих данных. Таким образом, диаграммы потоков данных являются альтернативой функциональным диаграммам в случае, когда программное обеспечение активно работает с различными хранилищами данных и/или имеет сложную структуру управления. Диаграммы «Сущность-связь», структуры и диаграммы отношений данных. С точки зрения составления спецификаций можно рассматривать структуры данных как совокупность правил и ограничений, которые отражают связи, существующие между отдельными частями (элементами) данных. То есть идет речь об абстрактных структурах данных, характеризующих только связь между элементами, в отличие от конкретных структур данных, характеризующих физическое представление данных в памяти ЭВМ и логическое – на каком либо языке программирования. Все абстрактные структуры данных можно разделить на три группы:
Представление данных первых двух групп не представляет сложности и осуществляется с помощью графического изображения множеств в первом случае и табличными структурами – во втором. Структуры третьей группы в общем случае представляются графовыми моделями. На практике часто необходимо вложение структур данных, в том числе и разных типов. В этом случае используются специальные модели, которые в зависимости от типов описываемых отношений принято делить на иерархические и сетевые. Иерархические модели позволяют описывать упорядоченные или неупорядоченные отношения вхождения элементов данных в компонент более высокого уровня, т. е. множества, таблицы и их комбинации. К иерархическим моделям относят модель Джексона-Орра, для графического представления которой можно использовать диаграммы Джексона или скобочные диаграммы Орра. Сетевые модели данных используют в тех случаях, если отношение между компонентами данных не исчерпываются включением. Для графического представления разновидностей этой модели используют несколько нотаций. Наиболее известной является нотация IDEF1 или более современный вариант этой нотации – IDEF1X, используемый в CASE-системах. 3.4 Модели этапа анализа требований и определения спецификаций при объектном подходе Модели разрабатываемого программного обеспечения при объектном подходе основаны на предметах и явлениях реального мира. В основе этих моделей также лежит описание требуемого поведения разрабатываемого программного обеспечения, т.е. его функциональности, но это поведение связывается с состояниями элементов (объектов) конкретной предметной области. В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, т.е. представление разрабатываемого программного обеспечения в виде совокупности объектов, в процессе взаимодействия которых через передачу сообщений и происходит выполнение требуемых функций. В настоящее время стандартным средством описания проектов фактически признан язык UML (Unified Modeling Language - унифицированный язык моделирования). Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: использования, логическую, реализации, процессов, развертывания. Для их представления используется набор графических нотаций – диаграмм. Описание основных шагов и используемых выразительных средств в последовательности их использования в процессе анализа требований и определения спецификаций приведено ниже. Определение вариантов использования системы. Вариант использования – характерная процедура применения разрабатываемой системы конкретным действующим лицом, в качестве которого могут выступать не только люди, но и другие системы или устройства. В качестве выразительного средства данного шага применяются диаграммы вариантов использования. Определение вариантов использования и построение диаграмм осуществляется в следующей последовательности:
Построение концептуальной модели предметной области. Концептуальные модели оперируют понятиями предметной области, атрибутами этих понятий и отношениями между ними. В качестве выразительного средства используются диаграммы классов концептуального уровня, называемые контекстными (диаграммы классов других уровней используются на более поздних этапах разработки). Основной задачей контекстных диаграмм классов является выделение основных понятий предметной области (им в соответствие ставятся классы) и связей между ними. На практике определение понятий предметной области, представляемых классами, не является тривиальной задачей, поэтому при разработке диаграмм классов используется следующая последовательность действий:
Описание поведения. В основе описания поведения лежит выделение так называемых системных событий – событий, генерируемых для системы действующими лицами. Системные события инициируют выполнение системой соответствующего множества операций, также называемых системными. В качестве выразительного средства используется диаграмма последовательностей системы – графическая модель, которая для определенного сценария варианта использования показывает генерируемые действующими лицами системные события и их порядок. Диаграмма последовательностей системы строится на основе анализа вариантов использования – идентифицируются действующие лица и для каждого варианта использования определяются множество системных событий и их последовательность. На основе полученного списка системных событий строится множество системных операций, которое присваивается специальному классу System. Каждая операция описывается в текстовом виде по установленной форме. Если на этапе анализа требований и определения спецификаций необходима конкретизация основных функций программного обеспечения, то можно использовать диаграммы деятельностей. Каждому варианту использования соответствует своя последовательность задач – деятельностей. Диаграммы деятельностей являются обобщенным представлением алгоритма. Также как и диаграммы классов они используются на различных этапах разработки, отличаясь лишь степенью абстракции. 4 Типовое содержание основной части отчета В данном случае под основной частью отчета понимаются разделы, в которых приводится описание результатов работы непосредственно по теме преддипломной практики. Основная часть состоит из двух разделов, соответствующих первым двум этапам процесса разработки программного обеспечения. Результаты выполнения первого этапа (в части определения назначения программного обеспечения, актуальности его разработки и т.п.) могут быть использованы для подготовки введения. Каждый раздел содержит подразделы, которые при необходимости могут быть разбиты на пункты. Ниже приведено типовое содержание разделов, которое не является обязательным и может варьироваться в зависимости от специфики темы по согласованию с руководителем преддипломной практики (особенно в случае исследовательских тем). Приведенные названия разделов и подразделов являются шаблонными и должны быть переформулированы в отчете в соответствии с конкретной темой. Курсивом в тексте выделены примечания. 1 Анализ предметной области и разработка требований к программному обеспечению. 1.1 Анализ структуры и взаимосвязей автоматизируемых информационных процессов. 1.2 Анализ взаимодействия и разграничения функциональных обязанностей разрабатываемой системы с внешним окружением (программное обеспечение, технические средства, люди). 1.3 Анализ методов решения поставленной задачи и существующих аналогов программного обеспечения. 1.4 Основные требования (функциональные и эксплуатационные) к программному обеспечению и принципы его разработки (принципиальные решения начальных этапов). 2 Определение спецификаций программного обеспечения. При структурном подходе: 2.1 Определение требуемого поведения программного обеспечения. 2.2 Построение функциональной модели программного обеспечения (функциональные диаграммы или диаграммы потоков данных). 2.3 Разработка абстрактных структур и/или схем данных. При объектном подходе: 2.1 Определение вариантов использования программного обеспечения. 2.2 Построение концептуальной модели предметной области. 2.3 Описание поведения программного обеспечения. Литература, которую следует добавить в список источников:
|
Добавить документ в свой блог или на сайт
Похожие:
 |
Доклад по защите выпускной квалификационной работы Обращение Уважаемые члены Государственной аттестационной комиссии! Вашему вниманию предлагается выпускная квалификационная работа на тему «Создание... |
|
Доклад по защите выпускной квалификационной работы Здравствуйте, уважаемые члены Государственной аттестационной комиссии! Я студент Коновалов Александр Михайлович. Вашему вниманию... |
 |
1. Организация процесса конструирования Определение технологии конструирования... Технология конструирования программного обеспечения (ткпо) — система инженерных принципов для создания экономичного по, которое надежно... |
|
Доклад по защите выпускной квалификационной работы Обращение Здравствуйте, уважаемые члены Государственной аттестационной комиссии! Я студент Коновалов Александр Михайлович. Вашему вниманию... |
|
Генерация кода по диаграмме активностей Продукт, вышедший на рынок первым, обладает несомненным преимуществом перед конкурентными разработками. Таким образом, в it-индустрии... |
|
Курсы, дата прохождения Награды Курсы «Применение пакета свободного программного обеспечения», 10. 12. 2009 г., Курсы повышения квалификации «Использование эор в... |
|
Программа построена согласно архитектуре mvc (Model-View-Controller)... В этом разделе описывается разработка программной системы – от проектирования структурных, функциональных и принципиальных схем и... |
|
Татьяна Горожанова Специализация: бытовое и промышленное кондиционирование воздуха, овкв, локализация программного обеспечения, искусство, мода |
|
Программа практики текстологическая практика Магистратура по направлению... Место практики в структуре ооп впо по направлению подготовки магистров «Филология» |
|
Курсовая работа по курсу «Организация и планирование производства» Целью курсовой работы является овладение базовыми экономическими понятиями, приобретение умения определять состав и величину затрат,... |