Жизненные циклы информационных систем

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

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

                                

 
 

3. Цикл жизни процесса

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

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

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

       Различные подходы могут применяться в  интерактивных системах. Во-первых, в интерактивной системе может  копироваться стратегия многозадачной системы с пакетной обработкой: с каждым терминалом связывается единственный процесс-сеанс (session). Таким образом, предельное число процессов в системе ограничивается числом терминалов. Пользователь каждого терминала работает как бы в однозадачной среде (VM). Во-вторых, для преодоления стесненности пользователя в сеансе система может позволять в ходе сеанса порождать дополнительные, фоновые (background) процессы. Такие процессы выполняют программы, не требующие в ходе выполнения взаимодействия с оператором. Фоновые процессы работают параллельно с процессом, поддерживающим интерактивную работу в сеансе. Наконец, в-третьих, система может позволять порождать любые процессы и в любом количестве. Для каждой новой выполняемой программы создается новый процесс, который уничтожается с завершением программы. Процессы могут выполняться как последовательно, так и параллельно, ограничением на количество параллельно выполняемых процессов является объем ресурсов вычислительной системы и ОС, в частности, возможные ограничения на предельный размер таблицы процессов. Подход без ограничений на число процессов иногда называют философией "дешевых" процессов. В таких системах "накладные расходы" на создание процессов минимальны и наблюдается тенденция к предельному упрощению отдельных процессов: каждый отдельный процесс реализует некоторую весьма элементарную функцию, а сложные действия реализуются как комбинации тех или иных элементарных действий.

       3.1 Иерархическая структура  связей между процессами

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

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

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

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

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

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

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

              

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Заключение

     Таким образом, из вышеизложенного, можно заключить, что жизненный цикл операционных систем – это сложный процесс программной инженерии и управление жизненным циклом ПО

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

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

 
 
 
 
 
 
 
 

Список  используемой литературы

 
 

1. М. Хохлова,  статья «Современный рынок систем  управления предприятием»

 

2. Д. Глямшин,  статья «Выход из кризиса –  система управления»

 

3. Ю. Токарев,  статья «Корпоративные информационные системы и консорциум разработчиков»

 

4. В. Баронов, И. Титовский, статья «Методы построения операционных систем. Системная инженирия»

 

5. В.П. Нестеров, И.Б. Нестеров, статья «Автоматизация деятельности организации»

 

6. С. Колесников, статья «Бизнес процесс реинжиниринг и внедрение автоматизированных систем управления»

 

7. С. Колесников, статья «Об оценке эффективности внедрения и применения ERP систем»

 

8. В.В. Липаев,  Лекции из курса «Программная инженерия. Методологические основы»

 

9. И.И. Карпачев, «Классификация компьютерных систем управления предприятием. Жизннный цикл операционных систем»

 

10. www.bsc-consulting.ru

 

11. www.erp-online.ru

 

12. www.LAWSON.com

 

13. www.erp-people.com

 

14. www.economics.ru