Технологическая карта урока



бет2/3
Дата06.02.2023
өлшемі111,5 Kb.
#65358
1   2   3
а) Пәнаралық байланыс / Межпредметная связь информатика, математика, ағылшын.
а) оқу-көрнекілік құралдар/ учебно-наглядные пособия Персональный компьютер, интерактивная доска, флипчард, раздаточные материалы.


Қолданатың әдебиет /Литература к занятию
P.А. Кадиркулов, Г.К. Нурмуханбетова. Информатика. Учебник для 10 кл.+ CD. Алматы кітап, 2019,
Өз бетінше жұмыс/Самостоятельная работа. Работа с компьютерами.
5. Сабақтың барысы /Ход занятия


Ұйымдасытру кезеңі / Организационный момент:

  1. Актуализация знаний учащихся

  2. Объяснение нового материала

  3. Практическая работа на компьютере

  4. Закрепление изученного материала



Білім алушылардың біліктілігі мен дағдысын тексеру/Проверка знаний и умений обучающихся (өткен тақырыпты пысықтау/ обобщение пройденной темы).
Аппаратные средства что это такое
Жаңа тақырыптың мазмұны мен жүйесі /Содержание и последовательность изложения новой темы
В настоящее время в развитии наук наблюдаются 2 противоположные тенденции:
1) Дифференциация, когда при увеличении знаний и появлении новых проблем из более общих наук выделяются частные науки.
2) Интеграция, когда более общие науки возникают в результате обобщения и развития тех или иных разделов смежных наук и их методов.
В основе процессов дифференциации и интеграции лежат 2 фундаментальных принципа материалистической диалектики:
1) принцип качественного своеобразия различных форм движения материи, необходимость изучать отдельные аспекты материального мира;
2) принцип материального единства мира, необходимость получать целостное представление о каких-либо объектах материального мира.
В результате проявления интегративной тенденции появилась новая область научной деятельности: системные исследования, которые направлены на решение комплексных крупномасштабных проблем большой сложности.
Системный анализ представляет собой новое научное направление интеграционного типа, которое разрабатывает системную методологию принятия решений и занимает определенное место в структуре современных системных исследований.

1) системные исследования;
2) системный подход;
3) конкретные системные концепции;
4) общая теория систем (метатеория по отношению к конкретным системам);
5) диалектический материализм (философские проблемы системных исследований);
6) научные системные теории и модели (учение о биосфере земли; теория вероятностей; кибернетика и др.);
7) технические системные теории и разработки — исследование операций; системотехника, системный анализ и др;
8) частные теории системы.
Рисунок 1.1 - Системный анализ
Накопленный к настоящему времени опыт создания систем ПО показывает, что это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени создание таких систем нередко выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ПО. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой-либо дисциплины проектирования, методом "code and fix" (кодирования и исправления ошибок).
Проблемы создания ПО следуют из его свойств. Еще в 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость [1]. Что же касается современных крупномасштабных проектов ПО, то они характеризуются, как правило, следующими особенностями:
Характеристики объекта внедрения:

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

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

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

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

Технические характеристики проектов создания ПО:

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

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

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

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

  • большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

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

Организационные характеристики проектов создания ПО:

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

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

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

  • высокие требования со стороны заказчика к уровню технологической зрелости организаций-разработчиков (наличие сертификации в соответствии с международными и отечественными стандартами).

В конце 60-х годов прошлого века в США было отмечено явление под названием "software crisis" (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, выглядели следующим образом:

  • только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

  • 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

  • 31,1% проектов были аннулированы до завершения;

  • для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

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

  • нечеткая и неполная формулировка требований к ПО;

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

  • отсутствие необходимых ресурсов;

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

  • частое изменение требований и спецификаций;

  • новизна и несовершенство используемой технологии;

  • недостаточная поддержка со стороны высшего руководства;

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

Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "программная инженерия" (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.
В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме "тушения пожара". Бессистемное применение технологий создания ПО (ТС ПО), в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации.
Одна из причин распространенности "хаотического" процесса создания ПО - стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой ТС ПО, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина - в "тяжести" технологических процессов. "Тяжелый" процесс обладает следующими особенностями:

  • необходимость документировать каждое действие разработчиков;

  • множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере;

  • отсутствие гибкости;

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





Достарыңызбен бөлісу:
1   2   3




©emirsaba.org 2024
әкімшілігінің қараңыз

    Басты бет