Файл: Методические указания по организации практических занятий и самостоятельной работы по мдк. 02. 01 Технология разработки программного обеспечения.docx

4.3.6 Требования к правовому обеспечению системы

4.3.7 Требования к программному обеспечению системы

4.3.8 Требования к техническому обеспечению

4.3.9 Требования к эргономическому обеспечению

5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ

6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

7 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ

8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

9 ИСТОЧНИКИ РАЗРАБОТКИ
Шаблон ТЗ задания приведен в приложении Б.
Задание практической работы

Изучить правила проведения анализа предметной области и составления ТЗ для «Туристической фирмы»
Методика выполнения

В качестве примера возьмем БД Туристическая фирма.

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

1. 
   Запустите MS Visio.
   
2. 
   В категориях шаблонов выберите Базы данных и в ней элемент Нотация Чена. Нажмите кнопку Создать.
   
3. 
   В соответствии с анализом предметной области необходимо добавить на рабочий лист три фигуры Сущность.
   
4. 
   Для добавления текста фигуре необходимо дважды щелкнуть по ней левой кнопкой мыши.
   

5. 
   Далее необходимо добавить связи между сущностями. Для этого необходимо использовать фигуру ромб.
   

6. 
   На данном этапе получена общая диаграмма Чена. Для ее детализации необходимо добавить атрибуты ко всем сущностям. Атрибуты изображаются в виде овала
   

7. 
   Запустите MS Visio.
   
8. 
   В категориях шаблонов выберите Базы данных и в ней элемент Нотация IDEF1X. Нажмите кнопку Создать.
   
9. 
   В соответствии с анализом предметной области необходимо добавить на рабочий лист три фигуры Сущность.
   
10. 
    Для добавления текста фигуре необходимо дважды щелкнуть по ней левой кнопкой мыши.
    

---

11. 
    Далее необходимо добавить связи между сущностями.
    

12. 
    Добавить имена атрибутам (и сами атрибуты при необходимости).
    

13. 
    Указать атрибуты, которые являются внешними ключами
    

Для этого нужно выделить атрибут. Щелкнуть по нему правой кнопкой мыши и в контекстном меню выбрать пункт «Задать внешний ключ».

14. 
    Создание физической модели
    

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

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

16. 
    Затем необходимо указать соответствующие типы данных, в зависимости от СУБД в которой будет выполняться реализация системы. Например, для MS Access модель примет вид:
    

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


Задание самостоятельной работы

В соответствии с индивидуальным вариантом, провести анализ предметной области, построить ER-модель в нотации Чена и IDEF1X и на основании ГОСТ 34.602-89, разработать документ Техническое задание.

Перечень индивидуальных вариантов приведен в приложении А.
Контрольные вопросы

1. 
   Что такое предметная область?
   
2. 
   Этапы анализа предметной области.
   
3. 
   Что такое ER-модель?
   
4. 
   В каких нотациях можно построить ER-модель?
   
5. 
   Элементы диаграммы Чена.
   
6. 
   Элементы диаграммы в нотации IDEF1X.
   
7. 
   Для чего предназначена диаграмма «сущность-связь»?
   
8. 
   Что представляет собой нормализация?
   
9. 
   В чем разница между логическим уровнем модели данных и физическим?
   
10. 
    Назначение, содержание и степень адаптивности стандарта ГОСТ 34.601-90?
    
11. 
    Стадии и этапы создания АС в соответствии с ГОСТ 34.601-90?
    
12. 
    Назначение, содержание стандарта ГОСТ 34.602-89?
    
13. 
    Назначение программного документа Техническое задание на создание АС. Порядок разработки, согласования и утверждения документа?
    
14. 
    Состав и содержание документа ТЗ?
    

---

---

Практическая работа №2

Построение архитектуры программного средства. Изучение работы в системе контроля версий
Цель: Изучение базовых принципов и шаблонов построения архитектуры приложений, выбор стратегии и шаблона проектирования, которые помогут при проектировании слоев, компонентов и сервисов решения, а также визуальное проектирование архитектуры приложения с использованием Microsoft Visio.

Изучить на практике понятия и компоненты систем контроля версий (СКВ), приемы работы с ними.Освоить специализированное ПО и распространенный сервис для работы с распределенной СКВ Git — TortoiseGit и GitHub.com.
Форма отчета:

С целью реализации начальных этапов разработки ПС в соответствии с техническим заданием:

• 
  создать архитектуру приложения.
  

Описать методику работы в системе контроля версий.
Теоретические сведения

Построение архитектуры программного средства

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

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

Всем понятно, что относятся они к тому, что и в какой последовательности должно делаться при создании и эксплуатации систем. Но прежде чем две организации или два специалиста договорятся о том, что конкретно входит или не входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две «стороны») все-таки по-разному понимают, какие работы будут входить в ЖЦ, а какие - нет, какие проверки будут планироваться, когда и т. д. Естественно, общие принципы организации работ описаны давно, но что делать сторонам в конкретном проекте — это каждый раз приходится решать заново.

---

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

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

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

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

В России основы построения и использования профилей стандартов ЖЦ ПС заложены принятием в качестве базового стандарта ГОСТ Р ИСО/МЭК 12207. Данный документ введен в действие с 1 июля 2000 г., тесно взаимоувязан с рядом стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения стандартов ИСО.

Актуальность стандарта ГОСТ Р ИСО/МЭК 12207 для современных условий настолько высока, что принятие в ISO его исходного, международного варианта вскоре вызвало самую положительную оценку российских экспертов. Был дан ряд рекомендаций по его использованию в реальных условиях.

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

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

---