1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения




Название1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения
Дата публикации14.05.2014
Размер198 Kb.
ТипАнализ
literature-edu.ru > Информатика > Анализ
Содержание

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 этапы.

  1. Постановка задачи. В процессе постановки задачи четко формулируют назначение программного обеспечения и определяют основные требования к нему.

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

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

  4. Реализация. Реализация представляет собой процесс поэтапного написания программных текстов модулей на выбранном языке программирования (кодирование), их тестирование и отладку.

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

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

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

2.1 Основное содержание этапа постановки задачи

На практике данный этап соответствует стадии «Техническое задание» в соответствии с ГОСТ 19.102-77 «Стадии разработки» и заканчивается разработкой технического задания на разработку программного продукта. В ходе преддипломной практики разработка такого документа не является обязательной, но содержание основных разделов технического задания тем или иным образом будет содержаться в отчете.

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

  • исходные данные и требуемые результаты, которые определяют функции программы или системы;

  • среда функционирования (программная и аппаратная) – может быть задана, а может выбираться для обеспечения параметров, указанных в техническом задании;

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Рассмотрим те разделы, содержание которых должно обязательно войти в материал отчета по преддипломной практике.

1. Раздел «Введение» должен содержать наименование и краткую характеристику области применения программного продукта, а также объекта (например, системы) в котором предполагается их использовать. Основное назначение введения – продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.

2. Раздел «Назначение разработки» должен содержать описание функционального и эксплуатационного назначения программного продукта с указанием категорий пользователей.

3. Раздел «Требования к программе или программному изделию» включает в себя несколько подразделов. Наиболее важные из них:

– требования к функциональным характеристикам;

– требования к составу и параметрам технических средств;

– требования к информационной и программной совместимости;

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

  • перечислены выполняемые функции;

  • описан состав, характеристики и формы представления исходных данных;

  • описан состав, характеристики и формы представления результатов.

В этом же разделе при необходимости указывают критерии эффективности: максимально допустимое время реакции системы, максимальный объем используемой оперативной и/или внешней памяти и др.

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

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

2.2 Предпроектные исследования предметной области

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

  1. Неизвестны методы решения формулируемой задачи – такого типа не определенности обычно возникают при решении научно-технических задач.

  2. Неизвестна структура автоматизируемых информационных процессов – обычно встречается при построении автоматизированных систем управления.

В первом случае предпроектные исследования осуществляются с целью определить:

  • возможность решения поставленной задачи;

  • методы решения поставленной задачи.

Во втором случае определяют:

  • структуру и взаимосвязи автоматизируемых информационных процессов;

  • распределение функций между человеком и системой, а также между аппаратным и программным обеспечением;

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

  • требования к программным и информационным компонентам, необходимые аппаратные ресурсы, требования к базам данных и физические характеристики программных компонент.

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

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

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

2.3 Принципиальные решения начальных этапов разработки

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

  • выбор архитектуры программного обеспечения;

  • выбор типа пользовательского интерфейса и технологии работы с документами;

  • выбор подхода к разработке (структурного или объектного);

  • выбор языка и среды программирования.

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

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

  • многопользовательскую архитектуру, которая рассчитана на работу в локальной или глобальной сети.

Кроме того, в рамках однопользовательской архитектуры различают:

  • программы;

  • пакеты программ;

  • программные комплексы;

  • программные системы.

Многопользовательскую архитектуру реализуют системы, построенные по принципу «клиент-сервер».

Выбор типа пользовательского интерфейса. Различают четыре типа пользовательских интерфейсов:

  • примитивные – реализуют единственный сценарий работы;

  • меню – реализуют множество сценариев работы, операции которых организованы в иерархические структуры;

  • со свободной навигацией – реализуют множество сценариев, операции которых не привязаны к уровням иерархии, и предполагают определение множества возможных операций на конкретном шаге работы;

  • прямого манипулирования – реализуют множество сценариев, представленных в операциях над объектами.

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

Кроме того, выбор типа интерфейса включает выбор технологии работы с документами. Различают две технологии:

  • однодокументная, которая предполагает однодокументный интерфейс (SDI – Single Document Interlace);

  • многодокументная, которая предполагает многодокументный интерфейс (MDI – Multiple Document Interface).

Многодокументную технологию используют, если программное обеспечение должно поддерживать работу с несколькими документами одновременно.

Выбор подхода к разработке. На данный момент существует два основных подхода к разработке: структурный и объектный.

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

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

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

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

  • универсальные языки высокого уровня;

  • специализированные языки разработчика программного обеспечения (языки запросов к базам данных, языки создания систем искусственного интеллекта и др.);

  • специализированные языки пользователя (являются частью профессиональных сред пользователя; от программиста может потребоваться их разработка);

  • языки низкого уровня (обычно Ассемблер; используются при реализации простых программ или вставок в программы на языках высокого уровня).

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

  • наличием в организации определенной среды разработки;

  • предпочтениями разработчика;

  • устоявшимся мнением о предпочтительности использования определенного языка для решения данного класса задач;

  • и др.

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

3.1 Спецификации и их классификация

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

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

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

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

3.2 Модели этапа анализа требований и определения спецификаций, не зависящие от подхода к разработке

К независящим от подхода к разработке относятся:

  • диаграммы переходов состояний;

  • математические модели предметной области.

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

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

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

  • анализ условия задачи;

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

  • формальную постановку задачи;

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

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

3.3 Модели этапа анализа требований и определения спецификаций при структурном подходе

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

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

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

  • диаграммы потоков данных (DFD – Data Flow Diagrams), описывающие взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

  • диаграммы «сущность-связь» (RRD – Entity-Relationship Diagrams), описывающие базы данных разрабатываемой системы и/или, в случае более простых форм организации данных, структуры и диаграммы отношений данных;

  • диаграммы переходов состояний (STD – State Transition Diagrams), характеризующие поведение системы во времени;

  • спецификации процессов (в виде текстового описания, схем алгоритмов на абстрактном уровне, псевдокодов и др.);

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

Функциональные диаграммы. Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого программного обеспечения. Например, активностная модель методологии 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. Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во MГТУ им. Н.Э. Баумана, 2002. - 320 с. (имеется в библиотеке)

  2. Орлов С.А. Технологии разработки программного обеспечения: Учебник. - СПб.: Питер, 2003. - 473 с. (имеется в библиотеке)

Добавить документ в свой блог или на сайт

Похожие:

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconДоклад по защите выпускной квалификационной работы Обращение
Уважаемые члены Государственной аттестационной комиссии! Вашему вниманию предлагается выпускная квалификационная работа на тему «Создание...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconДоклад по защите выпускной квалификационной работы
Здравствуйте, уважаемые члены Государственной аттестационной комиссии! Я студент Коновалов Александр Михайлович. Вашему вниманию...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения icon1. Организация процесса конструирования Определение технологии конструирования...
Технология конструирования программного обеспечения (ткпо) — система инженерных принципов для создания экономичного по, которое надежно...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconДоклад по защите выпускной квалификационной работы Обращение
Здравствуйте, уважаемые члены Государственной аттестационной комиссии! Я студент Коновалов Александр Михайлович. Вашему вниманию...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconГенерация кода по диаграмме активностей
Продукт, вышедший на рынок первым, обладает несомненным преимуществом перед конкурентными разработками. Таким образом, в it-индустрии...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconКурсы, дата прохождения Награды
Курсы «Применение пакета свободного программного обеспечения», 10. 12. 2009 г., Курсы повышения квалификации «Использование эор в...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconПрограмма построена согласно архитектуре mvc (Model-View-Controller)...
В этом разделе описывается разработка программной системы – от проектирования структурных, функциональных и принципиальных схем и...

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconТатьяна Горожанова
Специализация: бытовое и промышленное кондиционирование воздуха, овкв, локализация программного обеспечения, искусство, мода

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconПрограмма практики текстологическая практика Магистратура по направлению...
Место практики в структуре ооп впо по направлению подготовки магистров «Филология»

1 Место выполняемых в ходе практики работ в процессе разработки программного обеспечения iconКурсовая работа по курсу «Организация и планирование производства»
Целью курсовой работы является овладение базовыми экономическими понятиями, приобретение умения определять состав и величину затрат,...

Литература


При копировании материала укажите ссылку © 2015
контакты
literature-edu.ru
Поиск на сайте

Главная страница  Литература  Доклады  Рефераты  Курсовая работа  Лекции