Программный продукт и информационные технологии

Содержание

Введение………………………………………………………………..3

1. Понятие программного  продукта и его стандартизация………….4

2. Основы жизненного цикла  программных средств………………...10

3. Модели  жизненного цикла   программного продукта……………..18

  4.Определение фаз  жизненного цикла………………………………...23

            Заключение………………………………………………………………27

            Список литературы……………………………………………………...32

Введение.

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

Нужен ли программный продукту некий отличительный знак, подтверждающий его качество? Казалось бы, рыночная экономика дает отрицательный ответ  на этот вопрос - высокий спрос подтвердит качество товара. Своеобразным знаком качества часто служит громкое имя  поставщика, всем известный brand. И тем  не менее, серьезные компании стремятся  не только обеспечить качество, но и  подтвердить его официально, получив  сертификат, демонстрирующий, что все  внутренние процессы компании направлены на создание качественного продукта. Иначе говоря, работает система управления и обеспечения качеством. Наличие  такого сертификата - гарантия доверия  его обладателю со стороны клиентов и партнеров.

1. Понятие программного  продукта и его стандартизация.

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

ISO 9000-3 - система качества  для ПО Стандарт ISO 9000-3 включает  в себя все положения общего  стандарта ISO 9001, а также необходимые  дополнения к ним, относящиеся  к разработке, поставке и обслуживанию  ПО. ISO 9001 устанавливает требования  к системе качества поставщика  и позволяет оценивать его  возможности по проектированию  и поставке продукции, соответствующей  этим требованиям. 

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

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

элемент   программного   обеспечения (software item) – любая идентифицируемая часть   программного     продукта  ; основание (baseline) - формально утвержденная версия элемента

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

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

использования; этап (phase) - определенный сегмент работы; регрессионное тестирование (regression testing) - тестирование, позволяющее  убедиться в том, что изменения, внесенные с целью исправления  обнаруженных ошибок, не породили новых; репликация (replication) - копирование   программного     продукта   с одного носителя на другой. Важно отметить, что в большинстве пунктов стандарта поставщик обязывается не только определять соответствующие действия, но и оформлять их документально, регистрировать результаты и периодически анализировать, для того чтобы внести необходимые усовершенствования или полностью заменить.

Управление проектированием

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обслуживание

Поддержка заказчиков обсуждается  в стандарте ISO 9000-2. Сопровождение  системы, как правило, включает в  себя обнаружение и анализ несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию программных  ошибок; модификацию интерфейсов, что  необходимо в случае внесения добавлений или изменений в аппаратуру; функциональное расширение или улучшение производительности Все действия по сопровождению должны проводиться и контролироваться в соответствии с планом сопровождения, который заранее определяется и  согласовывается поставщиком и  заказчиком. В заключение нам остается лишь добавить, что технология разработки программного обеспечения - это целая  наука, которой в России, увы, почти  не учат. Отсюда явный дефицит хороших  менеджеров и специалистов по комплексным  проектам. Общие положения стандарта  по обеспечению качества - лишь верхушка айсберга. За пределами нашей статьи остались детали тех процессов, которые  реально обеспечивают качество конечного  продукта. Но это, как правило, "ноу  хау" компании

2. Основы жизненного цикла программных средств

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

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

определение потребностей;

исследование и описание основных концепций;

проектирование и разработка;

испытания системы;

создание и производство;

распространение и продажа;

эксплуатация;

сопровождение и мониторинг;

снятие с эксплуатации (утилизация).

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

Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3 –5) специалистов, которые:

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

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

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

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

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

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

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

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

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

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

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

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

• архитектура комплекса программ должна соответствовать текущим и перспективным целям и стратегическим, функциональным задачам, создаваемой системы, быть достаточно гибкой и допускать относительно простое, без коренных структурных изменений, развитие и наращивание функций и ресурсов системы в соответствии с расширением сфер и задач её применения;
• в структуре и компонентах ПС и системы следует предусматривать обеспечение максимально возможной сохранности инвестиций в аппаратные и программные средства, а также в базы данных при длительном развитии, сопровождении и модернизации системы;
• необходимо обеспечивать эффективное использование ресурсов в ЖЦ системы и минимизировать интегральные затраты на обработку данных в типовых режимах её функционирования с учетом эксплуатационных затрат и капитальных вложений в создание системы и программного продукта;
• должны быть обеспечены безопасность функционирования системы и надежная защита данных от ошибок, от разрушения или потери информации, а также авторизация пользователей, управление рабочей загрузкой, резервированием и оперативным восстановлением функционирования системы и программного продукта;
• для обеспечения перспективы развития жизненного цикла системы и комплекса программ целесообразно предусматривать возможность интеграции гетерогенных вычислительных компонентов и возможность переноса ПС и БД на различные аппаратные и операционные платформы на основе концепции и стандартов открытых систем;
• следует обеспечить комфортное обучение и максимально упрощенный доступ конечных пользователей к управлению и результатам функционирования системы и программного продукта на основе современных графических средств и наглядных пользовательских интерфейсов.

3. Модели  жизненного  цикла  программного продукта

Каскадная модель была введена  в 70 – 80 гг. Она удобна для однородных ПП, когда каждое приложение представляло собой единое целое.

Основные характеристики модели:

- Жизненный цикл разбивается  на этапы (фазы);

- Переход с этапа на  этап – только после полного  завершения текущего этапа;

- Этап завершается выпуском  полного комплекта документации, достаточной для того, чтобы работа  могла быть выполнена другой  командой разработчиков.

Главные характерные черты каскадной модели следующие:

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

циклические повторения реализованных  фаз с возможно более ранней фазы.

. Каскадная модель ЖЦПО.

В каскадной модели успешное окончание одной из фаз ЖЦПО означает достижение соответствующей цели инженерного  программирования.

К этим подцелям необходимо добавить еще две:

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

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

Основные достоинства:

Формирование полного  набора проектной документации в  конце работы над этапом. Документация отвечает критериям полноты и  завершенности;

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

Основные недостатки:

- Большие сроки от  анализа до завершения;

- Требования к ПО «заморожены»  в виде ТЗ до конца разработки.

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

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

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

Рассмотрим одно из усовершенствований идеальной каскадной модели –  пошаговую разработку.