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

<

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

Жизненный цикл программного обеспечения представляет собой процесс, включающий все этапы, начиная с момента принятия решения о разработке соответствующей программы и заканчивая завершением ее существования. Это базовое понятие в методологи проектирования информационных систем. Существует международный стандарт ISO/1ЕС 12207, который является основным нормативным документом, регламентирующим все этапы создания и функционирования программного обеспечения. Стандарт не предлагает конкретной модели жизненного цикла и конкретных методов разработки программного обеспечения, он не определяет в деталях вопросы технологии выполнения действий или решения задач, а только описывает общую структуру реализуемых процессов.

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

– приобретение, поставка, разработка, эксплуатация, сопровождение — это основные процессы;

– документирование, управление конфигурацией, обеспечение качества, аттестация, оценка, аудит — вспомогательные процессы;

– управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла — организационные процессы.

Разработка программного обеспечения предполагает:

– анализ системы;

– проектирование и программирование;

– оформление проектной и эксплуатационной документации;

– разработку документации по проверке работоспособности и качества программных продуктов;

– разработку документации по обучению персонала.

Эксплуатация программного обеспечения предполагает:

– внедрение компонентов программного обеспечения;

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

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

– обучение персонала;

– непосредственную эксплуатацию системы;

– развитие и модификацию системы.

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

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

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

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

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

 

052214 1004 2 Жизненный цикл информационный системы

 

Рис. 1– Разработка, использование и сопровождение программного обеспечения

 

Первоначально понятие жизненного цикла рассматривалось как цикл разработки. Однако понимание того, что стоимость программного обеспечения включает издержки в течение всего времени жизни системы, а не только затраты на разработку или исполнение программ, привело к естественной трансформации исходного понятия цикла разработки. Жизненный цикл — это проекция пользовательского понятия «время жизни» на понятие разработчика «технологический цикл (цикл разработки)». Комбинацией этих понятий объясняется происхождение самого термина «жизненный цикл программного обеспечения».

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

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

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

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

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

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

Если деятельность разработчиков программного проекта поддерживается на всех основных этапах жизненного цикла, т.е. проект ведется в условиях использования некоторой так называемой CASE-системы (Computer Aided Software Engineering), то заранее установлены определенные рамки, включая контрольные точки, когда менеджер должен организовывать управляющие воздействия. Это, естественно, ограничение вариантов развития проекта. И также естественно, что CASE-система навязывает априорное представление о жизненном цикле, фиксированное поддерживаемой моделью. В такой ситуации может возникнуть ложное впечатление о единственности модели жизненного цикла. В результате, когда приходится менять условия разработки, коллектив может оказаться не готов к этому.

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

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

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

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

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

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

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

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

Первой, по времени появления, и самой распространенной являлась каскадная модель (рис. 2).

 

052214 1004 3 Жизненный цикл информационный системы

    
 

Рис. 2. Каскадная модель жизненного цикла

 

Модель предполагает следующие свойства взаимодействия этапов:

модель состоит из последовательно расположенных этапов,

каждый этап полностью заканчивается до того как начнется следующий,

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

возврат к предыдущим этапам не предусматривается или крайне ограничен,

результат появляется только в конце разработки.

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

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

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

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

Перейдем к анализу объектно-ориентированных моделей жизненного цикла.

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

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

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

модель жизненного цикла,

действия,

нотация языка.

 В настоящее время объектно-ориентированный подход является одним из быстро развивающихся направлений в проектировании систем. Примером могут являться объектно-ориентированный анализ — методология разработки систем, предложенная Йорденом, объектно-ориентированное проектирование, объектно-ориентированное программирование, реализованное в многочисленных компиляторах C++, Object Pascal, Borland Pascal, Smalltalk.

Несмотря на различия, существующие в конкретных вариантах объектно-ориентированного подхода, все эти варианты объединяются несколькими основополагающими принципами:

инкапсуляция — такое свойство при котором объекты содержат описание атрибутов и действий одновременно,

наследование — такой метод определения объектов, при котором производные объекты (потомки) наследуют свойства (атрибуты и действия) от своих родителей,

полиморфизм — такое свойство объектов при котором действие с одинаковыми именами вызывают различное поведение для различных объектов.

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Задание 2. Разработать упрощенный проект автоматизированного рабочего места специалиста (экономиста) в соответствии с выполняемыми производственными обязанностями

 

Организационно-экономическая сущность задачи

  1. Наименование задачи: учет поставок материалов.
  2. Место решения задачи: бухгалтерия ООО «Золотая игла».
  3. Цель решения задачи: выявление недопоставки материалов.
  4. Периодичность решения задачи: ежемесячно до 1-го числа следующего месяца.
  5. Для кого предназначено решение задачи: для отдела маркетинга и руководства фирмы.
  6. Источники получения исходных документов: поставщики материалов.
  7. Информационная модель задачи.

    052214 1004 4 Жизненный цикл информационный системы052214 1004 5 Жизненный цикл информационный системы

    Рис. 1

  8. Экономическая сущность задачи: учет поставок материалов необходим для контроля ритмичности поставок, выявления отклонений от плана по поставщикам и видам материалов. На основании ведомости, получаемой в результате решения данной задачи, принимаются управленческие решения, касающиеся изменения планов поставок и выбора поставщиков на следующий плановый период.

    Описание входной информации

    В качестве входной информации используется документ «Приходная накладная».

      

      

      

      

      

      

      

      

      

    Наименование предприятия Золотая игла

     

    Дата 

    Код

    поставщика

    Наименование поставщика

      

      

     

    01.09.2007 

    10011 

    Пехорка 

      

      

               

      

      

               

      

      

    Код

    материала

    Наименование материала

    Единицы измерения

    <

    Количество

    поставленного материала

    План

    поставки

     

      

      

    1034 

    Лавсан 

    м 

    240 

    240 

     

      

      

      

      

      

      

      

     

      

      

      

      

      

      

      

      

      

    На основании этого документа создается следующий машинный документ.

    Приходная накладная

    Дата

    поставки

    Код

    поставщика

    Наименование

    поставщика

    Код

    материала

    Наименование материала

    Единицы

    измерения

    Количество поставленного материала

    План

    поставки

    d 

    i 

     

    k 

       

    Sijk

    P 

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

    «Приходная накладная»

    Имя реквизита

    Идентификатор

    Тип

    данных

    Длина

    Ключ

    сортировки

    Способ ввода

    реквизита

    Дата 

    Data 

    С 

    10 

     

    Вручную 

    Код

    поставщика

    KP 

    С 

    5 

    1 

    Автоматически из справочника

    Наименование поставщика

    NP 

    С 

    20 

     

    Автоматически из справочника

    Код

    материала

    KI 

    С 

    4 

    2 

    Автоматически из справочника

    Наименование материала

    NI 

    С 

    20 

     

    Автоматически из справочника

    Единицы

    измерения

    ED

    С

    2

     

    Автоматически

    из справочника

    Количество поставленного материала

    S 

    Ч 

    4 

     

    Вручную 

    План поставки

    Ч 

    4 

     

    Автоматически из справочника

    Будут различаться два типа данных: С – те, что не поддаются арифметической обработке, и числовые – Ч, которые ей поддаются.

    Количество документов за период: ежедневно до 30 шт.

    Описание контроля ввода документа:

    – код поставщика: контроль на диапазон значений (от 10000 до 10020);

    – код материала: контроль на диапазон значений (от 1020 до 1050).

    Описание условно-постоянной информации

    Для решения задачи используются два справочника:

  • Справочник поставщиков (НАИМПОСТ), служащий для расшифровки кодов поставщиков;
  • Справочник материалов (НАИММАТ), служащий для расшифровки кодов материалов.

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

    Описание структуры документа

    «Справочник поставщиков»

    Имя реквизита

    Идентификатор 

    Тип данных

    Длина 

    Ключ сортировки

    целые

    дробные

    Код поставщика

    KP

    С

    5

     

    1

    Наименование поставщика

    NP

    С

    20

       

    Адрес

    поставщика

    AP

    С

    20

       

    Расчетный счет поставщика

    QP

    С

    7

       

     

    Описание структуры документа

    «Справочник материалов»

    Имя реквизита

    Идентификатор 

    Тип данных

    Длина 

    Ключ сортировки

    целые

    дробные

    Код материала

    KI

    С

    4

     

    1

    Наименование материала

    NI

    С

    20

       

    Единица

    измерения

    ED

    С

    2

       

    План поставки 

    РР

    Ч 

    4 

       

     

     

     

    Описание результирующей информации

    Проектируем форму первичного документа

    Фактическое выполнение поставок за__________

    Код

    поставщика

    Код материала

    Факт 

    План 

    Процент

    выполнения плана

             

    Сумма по

    поставщику

     

    Сi

    PCi

     

     

    Описание структуры результирующего документа

    Описание структуры результирующего документа

    Фактическое выполнение поставок за___________

    Имя

    реквизита

    Идентификатор

    Тип

    данных

    Длина 

    Ключ

    сортировки

    Способ

    ввода

    реквизита

    целые

    дробные

    Код

    поставщика

    KP

    С

    5

     

    1

    Автоматически из справочника

    Код

    материала

    KI

    C

    4

       

    Автоматически из справочника

    Факт

    QT

    Ч

    4

       

    Вручную

    План  

    P

    Ч

    4

       

    Автоматически из справочника

    Процент

    выполнения

    плана

    PV

    Ч

    3

    2

     

    Вручную

     

    Количество документов за период: ежемесячно 1 шт.

    Количество строк в документе (в среднем): 30.

    Контроль правильности документа: логический контроль полученных сумм.

    Описание алгоритма решения задачи

    Для получения ведомости «Фактическое выполнение поставок» необходимо рассчитать три показателя:

  • сумма поставок, выполненная каждым поставщиком за месяц;
  • сумма поставок, рассчитанная на основании плана по каждому поставщику;
  • процент выполнения плана.

    Результаты выполняются по следующим формулам:

    052214 1004 6 Жизненный цикл информационный системы; 052214 1004 7 Жизненный цикл информационный системы; PV=052214 1004 8 Жизненный цикл информационный системы, где

    Sidk – сумма поставки k-го материала фактическая, выполненная i-м поставщиком датой d;

    Skiрр – сумма поставки k-го материала i-м поставщиком по плану;

    Сi – сумма поставок, выполненных i-м поставщиком;

    СРР – сумма поставок по каждому поставщику по плану;

    PV – процент выполнения плана.

    Решение задачи средствами MS Excel

    Лист 1 переименуем в лист с названием Справочник поставщиков. Создадим на рабочем листе таблицу справочника поставщиков и заполним ее данными (Рис. 1)

    052214 1004 9 Жизненный цикл информационный системы

    Рис. 1 Расположение таблицы «Справочник поставщиков» на рабочем листе

    Лист 2 переименуем в лист с названием Справочник материалов. Создадим на рабочем листе таблицу справочника материалов и заполним ее данными (Рис. 2)

    052214 1004 10 Жизненный цикл информационный системы

    Рис. 2 Расположение таблицы «Справочник материалов» на рабочем листе

    Лист 3 переименуем в лист с названием Приходная накладная. На рабочем листе создадим таблицу приходной накладной. В графы Дата поставки, Код поставщика, Код материала, Количество поставленного материала введем данные, а для автоматического формирования остальных граф введем формулы.

    052214 1004 11 Жизненный цикл информационный системы

    Рис. 3.1 Таблица «Приходная накладная» с введенными формулами

    052214 1004 12 Жизненный цикл информационный системы

    Рис. 3.2 Таблица «Приходная накладная» с введенными формулами

    052214 1004 13 Жизненный цикл информационный системы

    Рис. 4 Расположение таблицы «Приходная накладная» на рабочем листе

    Лист 4 переименуем в лист с названием Фактическое выполнение поставок. На листе Фактическое выполнение поставок создадим таблицу фактического выполнения поставок. Путем создания межтабличных связей заполним графу Код материала. Для расчета граф Факт, План, Процент выполнения плана введем формулы.

    052214 1004 14 Жизненный цикл информационный системы

    Рис. 5.1 Таблица «Фактическое выполнение поставок» с введенными формулами

    052214 1004 15 Жизненный цикл информационный системы

    Рис. 5.2 Таблица «Фактическое выполнение поставок» с введенными формулами

    052214 1004 16 Жизненный цикл информационный системы

    Рис. 6. Расположение таблицы «Фактическое выполнение поставок» на рабочем листе

    Лист 5 переименуем в лист с названием Ведомость. На рабочем листе Ведомость создадим форму
    ведомости фактического выполнения поставок. Путем создания межтабличных связей заполним ее.

    052214 1004 17 Жизненный цикл информационный системы

    Рис. 7 Форма ведомости ООО «Золотая игла»

    052214 1004 18 Жизненный цикл информационный системы

    Рис. 8.1 Форма ведомости ООО «Золотая игла» с введенными формулами

    052214 1004 19 Жизненный цикл информационный системы

    Рис. 8.2 Форма ведомости ООО «Золотая игла» с введенными формулами

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

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

     

  1. Информатика для юристов и экономистов / Под ред. С.В.Симонович–СПб.: Питер, 2008.
  2. Информационные технологии в экономике / Под ред. Ю.Ф. Симионова.–Ростов-н/Д: Феникс, 2006.
  3. Корнеев И.И., Машурцев В.А. Информационные технологии в управлении. – М.: ИНФРА-М, 2009.
  4. Майоров С.И. Информационный бизнес: коммерческое распространение и маркетинг.– М.: Финансы и статистика, 1993.
  5. Пещанская И. Экономика информационного общества // Российский экономический журнал. № 5– 6. 2006.
  6. Родионов И.И. Информационные ресурсы для предпринимателей.–М.: Электронные знания, 2004.
<

Комментирование закрыто.

MAXCACHE: 1.03MB/0.00189 sec

WordPress: 22.56MB | MySQL:117 | 2,452sec