Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Задачи и принципы прогнозирования






Задачи прогнозирования и планирования схожи:

1) установление цели развития;

2) отыскание путей развития;

3) определение ресурсов для достижения цели.

Различие заключается в том, что: при планирование цель – дерективная; пути – детерминированные; ресурсы – ограниченные. При прогнозировании цель – теоретически достижимая; пути – возможные; ресурсы – вероятные.

План в итоге имеет одно (оптимальное) решение, а прогноз имеет веер альтернативных решений.Принципов прогнозирования много.

А) системность, т.е. с возрастанием сложности информационных процессов необходим системный подход и к планированию и к прогнозированию;

В) непрерывность и обратная связь, т.е. уточнение прогноза во времени;

10. Роль Инженерии программного обеспечения

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

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

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

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

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

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

 

 

11. Качества ПО и качества процесса разработки(4 основные)






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.