Лекция 7. Общие замечания к модели разработки MSF. Часть 2

 

Управление рисками

 

Для большинства проектов управление рисками – важнейший фактор успеха. Чтобы справиться с проектом, проектная группа должна:

1) обучаться,

2) быстро адаптироваться к переменам,

3) предусматривать изменения,

4) действовать эффективно.

 

 

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

 

Ориентация на выпуск в срок

 

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

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

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

3) Предоставляет в распоряжение группы мощный инструмент принятия решений: все решения принимаются на основе их связи с выпуском продукта в срок.

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

 

Разбиение больших проектов на управляемые части

 

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

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

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

 

 

Подразделение больших проектов на компактные составляющие:

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

2) приносит удовлетворение от завершения промежуточных проектов, избавляя от ощущения безысходности, которое появляется у разработчиков больших проектов;

3) вовремя сигнализирует о проблемах, поскольку завершение отдельных проектов служит промежуточными этапами большого проекта; если сдача какого-то проекта задерживается, то группа имеет возможность скорректировать ход проекта в целом;

4) повышает качество конечного продукта, поскольку каждый внутренний проект проходит отдельный контроль качества;

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

 

Ежедневная сборка

 

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

1) минимизирует риски, связанные с интеграцией кода – при ежедневной сборке проблемы этого сорта выявляются на ранней стадии, что позволяет вовремя отладить модуль, вызвавший проблему, или изменить соответствующее проектное решение;

2) упрощает поиск причин проблемы – при таком подходе не только проще выявить некорректный код, но и выяснить, что и когда случается с продуктом, прежде чем он перестал работать;

3) снижает риск падения качества.

 

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

 

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

1) удачная компиляция всех файлов и компонентов;

2) удачная сборка всех модулей и компонентов;

3) отсутствие ошибок препятствующих запуску приложения;

4) прохождение теста на работоспособность.

 

Планирование “снизу-вверх”

 

Попросту говоря, работу должны планировать те, кто ее делает. Такой подход:

1) повышает точность оценок, поскольку в этом случае они основаны на опыте конкретного разработчика, уже решавшего подобные задачи, а не взяты “с потолка” руководителем;

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

 

Планирование – задача всей группы (таблица 1).

 

Таблица 1. Составление графика “снизу-вверх”

 

Планирование	Представитель проектной группы
Основной план	Менеджер программы
Промежуточные этапы	Руководитель группы
Процессы	Группа разработки
Задачи	Разработчик

 

 

Версии

 

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

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

 

Рекомендации по организации выпуска версий продукта:

1) Ориентируйтесь на продукт: всегда помните, что ваша главная задача – выпустить версию, реализующую все затребованные заказчиком функциональные возможности. Этот подход позволяет группе постоянно смотреть чуть-чуть вперед, не ограничиваясь текущей версией, и всегда помнить о необходимости выполнения требований заказчика в полном объеме.

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

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

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

5) Если версия не решает задач бизнеса или производства, прекратите работу над ней: всегда знайте, когда нужно остановиться. Если нет причин выпускать следующую версию, не выпускайте ее.

Цели разработки

 

В большинстве проектов цели разработки попадают в одну из следующих категорий:

1) Прототип: на стадии “Анализ” прототип служит удобным инструментом обмена мнениями и уточнения концепции. Прототип – это нефункциональная демонстрационная версия продукта, чаще всего лишь набор снимков с экрана или Web-страниц. Помните, что прототип лишь помогает проектной группе и заказчику достичь соглашения относительно концепции приложения и его пользовательского интерфейса

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

3) Альфа-, бета- и промежуточные версии: на стадии разработки проектная группа чаще всего создает две основных промежуточных версии – альфа и бета. Они демонстрируют постепенное слияние пользовательского интерфейса, продемонстрированного на прототипе, и технологий, проверенных концепт-системой. Альфа-версия отвечает на вопрос: “Вот так технология и интерфейс выглядят вместе. Есть ли какие-то серьезные проблемы?”. Бета-версия отвечает на вопрос: “Мы решили все основные проблемы и большинство мелких. Мы ничего не упустили?”. Эта фаза разработки завершается созданием “золотой” версии.

4) Золотая версия: на стадии “Стабилизация” именно эта версия передается ограниченному кругу пользователей для тестирования. По мере выявления и устранения ошибок и проблем, связанных с производительностью, следом за ней развертывают следующие выпуски. Окончательная “золотая” версия, которая появляется в конце стадии “Стабилизация”, сигнализирует о завершении проекта и передаче результатов заказчику.

 

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

 

 

Лекция 8. Предпроект

 

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

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

Результат фазы “Анализ” – предпроект – представляет собой документ, описывающий концепцию проекта. Он детализирует:

1) концепцию проекта,

2) рамки проекта,

3) исходную информацию,

4) требования бизнеса и производства,

5) проектные требования,

6) результаты,

7) риски.

Назначение концепции

 

Важно понимать, что анализ:

1) служит первой фазой планирования и проектирования;

2) позволяет добиться понимания и согласия между всеми участниками с самого начала проекта;

3) помогает группе объединить разные точки зрения в общую концепцию;

4) обеспечивает основу для будущего планирования;

5) выявляет факторы, которые заказчик и основные участники считают важнейшими для проекта.

 

Цитата Стива Синовски (в свое время вице-президент Microsoft по выпуску продукта Microsoft Office): Концепция важна потому, что она помогает команде принимать решения, наиболее подходящие для решения конкретной проблемы. В этом смысле хороша та концепция, которая является инструментом, позволяющим всем сотрудникам работать вместе для создания отличного продукта. Если над проектом работают 10 человек, они всегда могут узнать друг у друга все, что связано с проектом, что гарантирует общее понимание целей и действий. Когда же над проектом работает 1000 человек, нужен способ, обеспечивающий принятие решений без необходимости каждому участнику разговаривать с остальными 999.

 

 

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

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

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

3) Интеграцию – концепция продукта должна поддерживать и дополнять концепции и функциональные возможности других продуктов, использующихся в организации.

4) Будущие инвестиции – назначение концепции – не только направлять разработку сегодняшних продуктов, но и заложить основу на будущее.

Трудности фазы “Анализ”

 

1. Игнорирование динамической природы модели процесса разработки.
2. Неполное выполнение стадии “Анализ”
3. Непонимание того, что фаза “Анализ” закладывает основу для разработки сложных концепций.

 

Процесс исследования

 

Распределение обязанностей

 

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

 

Таблица 1 Обязанности ролей на стадии “Анализ”

 

Роль	Обязанности
Менеджер продукта	Подготовка документа “Концепция проекта” Работа с заказчиком Вовлечение заказчика в разработку прототипа Управление рисками
Менеджер программы	Формулировка целей проектирования Описание концепции решения Выявление структуры проекта Управление рисками
Разработчик	Разработка прототипов Выбор основных направлений разработки Выявление требований и взаимосвязей Управление рисками
Инструктор	Сбор требований, касающихся удобства использования Работа с пользователями Вовлечение пользователей в разработку прототипов Управление рисками
Тестер	Разработка стратегии тестирования Формулировка критериев приемки продукта Разработка системы выявления ошибок Разработка системы управления рисками Управление рисками
Логистик	Вопросы развертывания и их влияние на проект Вопросы сопровождения и их влияние на проект Управление рисками

 

 

Шаг 1: изучение

Шаг 2: анализ

Шаг 3: рационализация

Шаг 4: реализация

Шаг 5: утверждение

 

План проекта

 

Распределение ролей при планировании

 

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

 

Таблица Распределение обязанностей и ответственности на этапе “Планирование”

 

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

 

 

Стадии проектирования

 

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

 

Таблица Задачи стадий процесса проектирования MSF

 

Тип проектирования	Цель	Результат
Концептуальное	Учет требований пользователей, бизнеса и производства	Описание задачи и ее решение в терминах сценариев
Логическое	Учет требований проектной группы	Описание решения в виде набора взаимодействующих сервисов
Физическое	Учет требований разработчиков	Описание сервисов и технологий, необходимых для реализации решения

 

Дисциплина “Математическое моделирование и расчет теплотехнических систем на ЭВМ”

 

Задание 1

Вариант А.

Написать программу и численно решить нелинейное уравнение методами Ньютона и простой итерации, дихотомии.

, при xÎ(-2, -1), точность e=0.01

Ответ:

x=-1.272

 

Вариант Б.

 

Написать программу и численно решить нелинейное уравнение методами Ньютона и простой итерации, дихотомии.

, при xÎ(-1, 0), точность e=0.01

корень x=-0.821

 

 

 

Задание 2

 

Вариант А

 

Вычислить значение определенного интеграла аналитически и численно методами левых, правых и средних прямоугольников, трапеций и парабол (Симпсона) при N=5 и N=51, а также методом Эйлера и Монте-Карло. Сравнить результаты. Представить отчет по проделанной работе.

 

Ответ:

 

а) аналитически J=7.66

б) по методу средних прямоугольников при N=5 J=7.625, при N=51 J=7.66

в) по методу трапеций при N=5 J=7.75, при N=51 J=7.66

г) по методу парабол при N=5 J=7.66, при N=51 J=7.66

д) по методу левых прямоугольников при N=5 J=5.75, при N=51 J=7.50

е) по методу правых прямоугольников при N=5 J=9.75, при N=51 J=7.82

ж) по методу Эйлера J=7.66

з) Монте-Карло при N=100 J=5.94; при N=1000 J=7.38; при N=10000 J=7.53;

 

Вариант Б

 

Вычислить значение определенного интеграла аналитически и численно методами левых, правых и средних прямоугольников, трапеций и парабол (Симпсона) при N=5 и N=51, а также методом Эйлера и Монте-Карло. Сравнить результаты. Представить отчет по проделанной работе.

 

Ответы:

а) аналитически J=9.66

б) по методу средних прямоугольников при N=5 J=9.625, при N=51 J=9.66

в) по методу трапеций при N=5 J=9.75, при N=51 J=9.66

г) по методу парабол при N=5 J=9.66, при N=51 J=9.66

д) по методу левых прямоугольников при N=5 J=7.75, при N=51 J=9.50

е) по методу правых прямоугольников при N=5 J=11.75, при N=51 J=9.82

ж) по методу Эйлера J=9.66

з) Монте-Карло при N=100 J=9.30; при N=1000 J=9.42; при N=10000 J=9.55;

Задание 3

 

Вариант А

 

Написать программу (две версии – одна без массивов, вторая – с массивами) и численно решить обыкновенное дифференциальное уравнение методом Эйлера и Рунге-Кутта:

, y(0)=1.0; h=0.2, xÎ[0,1]

Первоначально протестировать алгоритм программы на примере

, y(0)=0; h=0.2, xÎ[0.1]. Точное решение y=x

 

Ответы:

Метод Эйлера

 

x	y
	1.0
0.2	1.2
0.4	1.373
0.6	1.531
0.8	1.681
1.0	1.826

 

Метод Рунге-Кутта

 

x	y
	1.0
0.2	1.183
0.4	1.342
0.6	1.483
0.8	1.613
1.0	1.732

 

Вариант Б

 

Написать программу (две версии – одна без массивов, вторая – с массивами) и численно решить обыкновенное дифференциальное уравнение методом Эйлера и Рунге-Кутта:

, y(0)=-1.0, h=0.1, xÎ[0,0.5]

Первоначально протестировать алгоритм программы на примере

, y(0)=0; h=0.2, xÎ[0.1]. Точное решение y=x

 

Ответы

 

Метод Эйлера

 

x	y
	-1.0
0.1	-0.975
0.2	-0.950
0.3	-0.923
0.4	-0.893
0.5	-0.857

 

Метод Рунге-Кутта

 

x	y
	-1.0
0.1	-0.975
0.2	-0.950
0.3	-0.922
0.4	-0.889
0.5	-0.849

 

 

Задание 4

 

 

Вариант А

 

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

 

Уравнение стационарной теплопроводности:

Граничные условия:

x = 0: T = T ₁;

x = Lx:

Параметры задачи: число узлов N=11; толщина пластины Lx=0.2 м; коэффициент теплопроводности λ=460 Вт/(м·К); коэффициент теплоотдачи a=500 Вт/(м²·K); температура на левой границе T1=293 К; температура на правой границе Te=423 K;

 

Ответ

X T

0.000 293.000

0.020 294.893

0.040 296.843

0.060 298.847

0.080 300.905

0.100 303.016

0.120 305.179

0.140 307.393

0.160 309.658

0.180 311.972

0.200 314.335

 

Вариант Б

 

 

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

 

Уравнение стационарной теплопроводности:

Граничные условия:

x = 0: T = T ₁;

x = Lx:

Параметры задачи: число узлов N=16; толщина пластины Lx=0.15 м; коэффициент теплопроводности λ=384 Вт/(м·К); коэффициент теплоотдачи a=1000 Вт/(м²·K); температура на левой границе T1=323 К; температура на правой границе Te=673 K;

 

Ответ

X T

0.000 323.000

0.010 328.591

0.020 334.271

0.030 340.040

0.040 345.895

0.050 351.835

0.060 357.860

0.070 363.966

0.080 370.152

0.090 376.418

0.100 382.761

0.110 389.179

0.120 395.671

0.130 402.236

0.140 408.871

0.150 415.575

 

Задание 5

Вариант А

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

 

Уравнение стационарной теплопроводности:

Граничные условия:

x = 0: T = T ₁;

x = Lx:

Параметры задачи: число узлов N=11; толщина пластины Lx=0.2 м; коэффициент теплопроводности λ=460 Вт/(м·К); коэффициент теплоотдачи a=500 Вт/(м²·K); температура на левой границе T1=293 К; температура на правой границе Te=423 K; приведенная степень черноты ε=0.5; постоянная Стефана-Больцмана σ=5.669*10^-8 Вт/(м²·К⁴); точность итерационного процесса d=0.00001

 

Ответ

X T

0.000 293.000

0.020 294.883

0.040 296.823

0.060 298.817

0.080 300.865

0.100 302.966

0.120 305.119

0.140 307.323

0.160 309.578

0.180 311.882

0.200 314.235

Вариант Б

 

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

 

Уравнение стационарной теплопроводности:

Граничные условия:

x = 0: T = T ₁;

x = Lx:

Параметры задачи: число узлов N=16; толщина пластины Lx=0.15 м; коэффициент теплопроводности λ=384 Вт/(м·К); коэффициент теплоотдачи a=1000 Вт/(м²·K); температура на левой границе T1=323 К; температура на правой границе Te=673 K; приведенная степень черноты ε=0.5; постоянная Стефана-Больцмана σ=5.669*10^-8 Вт/(м²·К⁴); точность итерационного процесса d=0.00001

 

 

Ответ

X T

0.000 323.000

0.010 328.575

0.020 334.239

0.030 339.991

0.040 345.830

0.050 351.755

0.060 357.763

0.070 363.853

0.080 370.024

0.090 376.273

0.100 382.600

0.110 389.002

0.120 395.479

0.130 402.027

0.140 408.647

0.150 415.335

 

Задание 6

 

Вариант А

 

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

 

Уравнение нестационарной теплопроводности:

Начальные условия:

t = 0: T=T₀

Граничные условия:

x = 0: T = T ₁;

x = Lx: T =T₂;

Параметры задачи: число узлов N=11; время расчета 60 с; толщина пластины Lx=0.1 м; коэффициент теплопроводности λ=46 Вт/(м·К); плотность 7800 кг/м³; коэффициент теплоемкости c=460 Дж/(кг·К); начальная температура T0=293 К; температура на левой границе T1=573 К; температура на правой границе T2=373 K;

 

Ответ

X T

0.00 573.00

0.01 518.02

0.02 467.10

0.03 423.62

0.04 389.81

0.05 366.59

0.06 353.69

0.07 349.90

0.08 353.38

0.09 361.90

0.10 373.00

 

Вариант Б

 

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

 

Уравнение нестационарной теплопроводности:

Начальные условия:

t = 0: T=T₀

Граничные условия:

x = 0: T = T ₁;

x = Lx: T =T₂;

Параметры задачи: число узлов N=21; время расчета 30 с; толщина пластины Lx=0.2 м; коэффициент теплопроводности λ=384 Вт/(м·К); плотность 8800 кг/м³; коэффициент теплоемкости c=381 Дж/(кг·К); начальная температура T0=273 К; температура на левой границе T1=323 К; температура на правой границе T2=673 K;

 

 

Ответ

X T

0.00 323.00

0.01 322.58

0.02 322.52

0.03 323.18

0.04 324.90

0.05 328.04

0.06 332.93

0.07 339.90

0.08 349.23

0.09 361.19

0.10 375.98

0.11 393.77

0.12 414.63

0.13 438.57

0.14 465.49

0.15 495.22

0.16 527.46

0.17 561.85

0.18 597.92

0.19 635.16

0.20 673.00