ОПИ-2. Министерство науки и образования рф
 Скачать 1.52 Mb.
|
|
ТЕМА 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ 13.1. Документация, создаваемая и используемая в процессе разработки программных средств При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС. Эту документацию можно разбить на две группы: Документы управления разработкой ПС. Документы, входящие в состав ПС. Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) - лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов : Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС. Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами. Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС. Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС. Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками. Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) - во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением: Пользовательская документация ПС (П-документация). Документация по сопровождению ПС (С-документация). 13.2. Пользовательская документация программных средств Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ. В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему. Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС . Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника). В соответствии с работами можно считать типичным следующий состав пользовательской документации для достаточно больших ПС: Общее функциональное описание ПС. Дает краткую характеристику функциональных возможностей ПС. Предназначено для пользователей, которые должны решить, насколько необходимо им данное ПС. Руководство по инсталяции ПС. Предназначено для администраторов ПС. Оно должно детально предписывать, как устанавливать системы в конкретной среде, в частности, должно содержать описание компьютерно-считываемого носителя, на котором поставляется ПС, файлы, представляющие ПС, и требования к минимальной конфигурации аппаратуры. Инструкция по применению ПС. Предназначена для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для ее изучения. Справочник по применению ПС. Предназначен для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска отдельных деталей. Руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру. Как уже говорилось ранее (см. лекцию 4), разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя (в противном случае это ПС, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками ПС, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользовательской документации разработан ряд стандартов, в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание. Документация по сопровождению программных средств Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение - это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, - с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков- сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС. Документация по сопровождению ПС можно разбить на две группы: 1. документация, определяющая строение программ и структур данных ПС и технологию их разработки; 2. документацию, помогающую вносить изменения в ПС. Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы: Внешнее описание ПС (Requirements document). Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы (подсистемы). Для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля. Для каждого модуля - его спецификация и описание его строения (design description). Тексты модулей на выбранном языке программирования (program source code listings). Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС. Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым рекомендациям и стандартам. Документация второй группы содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно- зависимыми. Общая проблема сопровождения ПС - обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда ПС изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть отражены в руководстве по сопровождению, и зафиксированы в базе данных управления конфигурацией. Тема 14. Технико-экономическое обоснование проектов программных средств Понятие технико-экономического обоснования программного средства. Экономика жизненного цикла ПС. Приступая к разработке крупных проектов, руководители, прежде всего, пытаются понять целесообразно ли их создание и оценить какова будет возможная эффективность применения готового продукта, оправдаются ли затраты на его разработку и использование. Поэтому такие проекты традиционно начинаются с анализа и разработки технико-экономического обоснования (ТЭО) предстоящего жизненного цикла (ЖЦ) проекта и эксплуатации предполагаемого продукта. Заказчику проекта необходимо оценить реальную потребность в его создании и возможную конкурентоспособность, а потенциальному разработчику-поставщику создаваемого продукта, провести оценку реализуемости проекта в условиях и ресурсах, предлагаемых заказчиком. Должен быть подготовлен согласованный между заказчиком и разработчиком первичный документ, в котором определены цели и задачи проекта, предполагаемые характеристики продукта и необходимые ресурсы для его реализации. Эти данные должны быть предварительно сбалансированы обеспечивать реализацию целей проекта при выделенных ресурсах с минимальным допустимым риском. Однако масштабы целей и функций сложных проектов имеют устойчивую тенденцию изменяться и увеличиваться по мере развития, а первоначально выделяемые ресурсы не удовлетворять их реализацию. Технико-экономическое обоснование проектов на начальном этапе их развития должно содержать оценки рисков реализации поставленных целей, обеспечивать возможность планирования и выполнения жизненного цикла продукта или указывать на недопустимо высокий риск его реализации и целесообразность прекращения разработки. Массовое создание сложных программных средств промышленными методами и большими коллективами специалистов вызвало необходимость их четкой организации, планирования работ по затратам, этапам и срокам реализации. Совокупные затраты в мире на такие разработки составляют миллиарды, а для отдельных проектов - миллионы долларов в год, поэтому требуется тщательный анализ эффективности создания и использования ПС. Для решения этих задач формируется новая область знания и научная дисциплина - экономика жизненного цикла программных средств как часть экономики промышленности и вы- числительной техники в общей экономике государств и предприятий. Развитие этой области экономики связано с большими трудностями, типичными для новых разделов науки и техники, появляющихся на стыке различных областей знания. В данном случае особенности состоят в том, что руководители и разработчики комплексов программ, как правило, не знают даже основ экономики разработки и производства сложной продукции, а экономисты не представляют сущность объектов разработки - программных средств, а также особенностей их создания, техноло- гического процесса и применения. Объективно положение осложнено трудностью измерения характеристик таких объектов. Широкий спектр количественных и качественных показателей, которые с различных сторон характеризуют содержание этих объектов, и невысокая достоверность оценки их значений, определяют значительную дисперсию при попытке описать и измерить свойства соз- даваемых или используемых ПС. Особенности развития методов и процессов технико-экономического обоснования проектов ПС обусловлены, в частности, сложностью, и, в ряде случаев, неопределенностью характеристик предполагаемого продукта, технологических этапов и процессов разработки, производства и применения программ для ЭВМ. При разработке комплексов программ сложно переплетаются содержание, этапы и распределение работ, возможен ряд возвратов на более ранние технологические этапы в процессе создания компонентов ПС, они имеют не совсем определенные границы начала и завершения. Специалисты в коллективе могут на некотором интервале времени решать несколько производственных задач и заменять друг друга. Положение усугубляется трудностью поэтапного определения качества компонентов и его прогнозирования в процессе разработки, что непосредственно отражается на технико-экономических показателях (ТЭП) проекта в целом. Следствием этого являются большие ошибки при планировании сроков, трудоемкости и стоимости создания ПС. Эта стихийность при создании крупных комплексов программ в большинстве случаев приводит к значительному запаздыванию разработок и превышению предполагавшихся затрат. Практика последних лет показывает, что вследствие пренебрежения тщательным технико-экономическим обоснованием, до 15% проектов сложных программных комплексов не доходит до завершения, а почти половина проектов не укладывается в выделенные бюджет и сроки и не обеспечивает требуемые характеристики качества. Типичны ситуации, когда отставание сроков внедрения промышленных систем управления и обработки информации полностью зависит от неготовности программ для них. Для небольших относительно простых проектов ПС, во многих случаях достаточно достоверными могут быть интуитивные оценки требуемых ресурсов, выполняемые опытными руководителями, реализовавшими несколько аналогичных проектов. При начале проектировании крупных ПС, требующих заведомо больших экономических, трудовых и временных затрат, необходима хотя бы приближенная, формализованная их оценка по определенной методике. Интуитивные оценки руководителями и исполнителями - размеров, сложности и трудоемкости конкретных программных проектов, как правило, отличаются существенными недостатками: - человек, в основном оптимистичен, и каждому хочется, чтобы проект ПС было меньше по размеру и более простым, что ведет к первоначальным недооценкам его сложности и к конфликтным ситуациям при разработке; - человек обычно не полностью использует предыдущий опыт о сложности функций аналогичных ПС и, особенно, о большом размере вспомогательных компонентов комплексов программ, которые также должны быть разработаны; - отдельные специалисты, как правило, не знакомы со всем объемом проекта и пожеланиями пользователей, что приводит к недооценке второстепенных функций и компонентов ПС, к отсутствию реалистичного применению накопленных знаний при оценивании размера и сложности проекта. Эти обстоятельства приводят к большим ошибкам оценивания ТЭП на начальных этапах разработки, которые можно значительно сократить при относительно небольших усилиях, применяя, в частности, формализованные методики экспертной оценки основных технико- экономических характеристик проектов комплекса программ. Тем самым проекты сложных ПС с самого начала могли бы выполняться с учетом более достоверной оценки необходимых ресурсов. Следствием недостатков или отсутствия технико-экономическим обоснованием проектов новых ПС являются острые конфликты между заказчиками и разработчиками. Часто разработчики ПС не в состоянии привести заказчику или руково- дителю проекта достаточно обоснованные доказательства не реальности выполнения выдвигаемых требований и предложенных ограниченных бюджета и сроков. Это приводит к оптимистической переоценке выгод новой программной разработки, к недооценке роли других конкурирующих предложений при заключении контрактов на разработку, и вследствие этого - к неизбежным перерасходам средств и к снижению качества ПС. Руководители конкретных проектов обычно не в состоянии достаточно обоснованно определять, сколько времени и затрат труда потребуется на каждый этап и работу программной части проекта системы. Вследствие этого, они не могут оценить, насколько успешно выполняется имеющийся план разработки ПС. Это, как правило, означает, что программная часть проекта системы с самого начала выходит из-под контроля и возможна катастрофа с реализацией и завершением проекта всей системы в требуемый срок с заданным качеством. Большую часть этих негативных последствий можно избежать, используя существующие, достаточно точные методы оценивания и прогнозирования затрат, а также управления проектами ПС, для их успешного завершения. Эти последствия объясняются многими причинами, из которых наиболее важными, являются следующие: - исходные тексты программных компонентов различны и по отдельности не определяют сложность и размер конечного продукта; - разработка сложных ПС требует творчества и сотрудничества разных специалистов, индивидуальное и групповое поведение которых, как правило, трудно предсказать; - в области экономики жизненного цикла ПС накоплен относительно небольшой опыт количественных оценок, и его трудно увеличивать, проводя и не обобщая разрозненные эксперименты. За последние несколько лет ряд исследований и работ по сбору и обобщению экономических данных о ЖЦ ПС заложили основы для методов и моделей оценивания затрат, которые обладают удовлетворительной точностью. Современная экономическая модель оценки разработки ПС считается хорошей, если с ее помощью можно оценить затраты на программную разработку с точностью 20 % в 70% случаев, при условии использования модели, в классе проектов, на которые она ориентирована. Имеющиеся модели не всегда столь точны, как хотелось бы, но могут весьма существенно помочь в технико-экономическом анализе и обосновании решений при создании сложных ПС. Необходимы дальнейшие, активные исследования на разных уровнях детализации, начиная от экономики и планирования создания программных средств в масштабах страны или предприятия и кончая экономикой выполнения частных операций отдельными специалистами при разработке или производстве конкретных ПС. Одна из важнейших задач состоит в том, чтобы увязать четкими экономическими категориями взаимодействие разных специалистов и предприятий в типовой производственной цепочке: заказчик - разработчик - изготовитель - пользователь. Для этого объект потребления - программное средство и все процессы взаимодействия в цепочке должны быть связаны системой экономических и технических характеристик, в той или иной степени, использующих основные экономические показатели - реальные затраты ресурсов: финансов, труда и времени специалистов на конечный продукт. Для решения этой задачи необходимо детально исследовать требуемые ресурсы современных процессов создания и использования программ различных классов и назначения - встроенных, коммерческих, административных, учебных, уникальных и др. Только на базе серьезных статистических исследований технико-экономических показателей жизненного цикла и практического маркетинга ПС возможны обобщения и создание теоретических и практических основ экономики ПС. Перечисленные выше проблемы и задачи требуют для своего решения выполнения крупных, комплексных научно-исследовательских работ, многие из которых еще не поставлены и далеки от разрешения. |