Общее понятие — доступные ресурсы обеспечения жизненного цикла ПС — включает реальные финансовые, временные, кадровые и аппаратурные ограничения затрат, в условиях которых происходит создание и совершенствование комплексов программ. В зависимости от характеристик объекта разработки на ее выполнение выделяются ресурсы различных видов и размеров.
Эти факторы проявляются как дополнительные характеристики процессов ЖЦ и программных продуктов, а также их рентабельности, которые следует учитывать и оптимизировать. В результате доступные ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов разработки, на достигаемые качество и эффективность применения программных продуктов. Многие проекты систем терпели и терпят неудачу из-за отсутствия у разработчиков и заказчиков при подготовке контракта четкого представления о реальных финансовых, трудовых, временных и иных ресурсах, необходимых для их реализации. Поэтому одной из основных задач при проектировании ПС является экономический анализ и определение необходимых ресурсов для создания и обеспечения всего ЖЦПС в соответствии с требованиями контракта и технического задания.
Учить/Не учить. Вся База Программирования.
Наиболее общим видом ресурсов, используемых в жизненном цикле ПС, являются допустимые финансово-экономические затраты или эквивалентные им величины трудоемкости соответствующих работ (см. лекцию 5). При разработке, тестировании и анализе качества этот показатель может применяться или как вид ресурсных ограничений, или как оптимизируемый критерий, определяющий целесообразную функциональную пригодность ПС. При этом необходимо также учитывать затраты на разработку, закупку и эксплуатацию системы качества, на технологию и комплекс автоматизации проектирования программ и баз данных, которые могут составлять существенную часть совокупной стоимости и трудоемкости разработки и всего ЖЦ ПС.
Затраты в жизненном цикле ПС определяются не только этапами разработки, но и этапами эксплуатации и сопровождения. Затраты на этих этапах могут значительно превышать затраты при разработке и характеризуются своими особыми закономерностями.
Однако эффективность процесса разработки ПС невозможно определять без учета эффективности последующей эксплуатации, а для долго модифицируемых программ — без оценки эффективности их сопровождения. Ряд факторов влияет на затраты при разработке сложных ПС не только непосредственно, но и через возможное изменение затрат в дальнейшем при сопровождении или эксплуатации. Каждый из этапов: разработка, сопровождение и эксплуатация — может быть достаточно длительным. В пределах этапов различные группы затрат могут быть неодновременными и разделяться интервалами времени, исчисляемыми годами. Однако разновременность затрат трудно учитывать в общем виде и при существующих методиках имеется некоторая условность при оценке влияния времени на совокупные затраты проекта.
В соответствии с этапами жизненного цикла ПС основные затраты С снижающие идеальную эффективность за цикл жизни tж, можно представить следующими составляющими (рис. 9.1):
MS Project 2013 — Типы ресурсов (Урок #25)
СР— совокупные затраты на разработку программ и обеспечение решения заданных функциональных задач, в том числе на технологическое обеспечение и аппаратуру ЭВМ при разработке ПС, в течение времени tP
Сс— затраты на сопровождение ПС за время t c, включающие затраты на хранение и контроль их состояния, проведение модернизаций и исправление ошибок, тиражирование версий;
Сэ— затраты на эксплуатацию программ и аппаратные средства ЭВМ, реализующих ПС, а также совокупные потери эффективности за время tэ, вследствие ограниченных характеристик ЭВМ и неидеальности программ.
В результате совокупные затраты ресурсов на программное средство за весь жизненный цикл длительностью 1Ж можно представить в виде
суммы: СР + Сс+ Сэ. В зависимости от назначения и области использования программ экономическую эффективность целесообразно анализировать интегрально за весь период жизни, либо дифференциально за единицу времени (месяц, год). Для совместного анализа составляющих, определяющих эффективность, необходимо унифицировать методы временного анализа и единицы измерения составляющих затрат. При последующем изложении затраты рассматриваются на длительности цикла жизни или на соответствующих интервалах времени: разработки, эксплуатации и сопровождения.
Разработка сложного ПС требует во много раз больших затрат, чем производство каждого экземпляра при массовом тиражировании. Поэтому далее производство базового образца программ не выделяется в самостоятельный этап, а рассматривается совместно с процессом разработки ПС. Производство серийных образцов программного продукта включается в этап эксплуатации. Экономическая эффективность разработки и распределение ресурсов на ее выполнение могут значительно изменяться в зависимости от того, является ПС уникальным или будет изготовлен в сотнях экземпляров. Это обстоятельство привело к целесообразности оценки затрат на разработку ПС не только в абсолютных значениях для опытного или базового образца, но и в относительных величинах доли затрат на программы в каждом экземпляре реализующей (целевой) ЭВМ при серийном производстве систем.
При выделении составляющих затрат на разработку программ целесообразно учитывать их относительный вес в суммарных затратах и возможность локализации групп специалистов, влияющих на величину этих затрат. Разработка программ является областью с малой материало- и энергоемкостью, и основные затраты связаны с непосредственным или овеществленным трудом специалистов различных категорий. Поэтому для измерения затрат наиболее универсальной единицей стала трудоемкость в человеко-месяцах или человеко-годах. При этом учитываются все категории специалистов, участвующих непосредственно или косвенно в создании данного ПС.
Время или допустимая длительность разработки определенных компонентов и версий ПС является невосполнимым ограниченным ресурсом реальных проектов. Этот ресурс все больше определяет достижимое качество сложных комплексов программ в процессе их разработки и сопровождения. Высокие требования заказчиков к сжатым срокам реализации проектов, естественно, ограничивают разработчиков и испытателей в продолжительности и объеме возможного системного анализа и проектирования, разработки и, особенно, тестирования программ. Увеличение числа привлекаемых для этого специалистов, при опытной эксплуатации или бета-тестировании, только в некоторых пределах позволяет ускорять разработку и увеличивать совокупное число тестов при проверках для повышения качества программ.
Доступные разработчикам ПС вычислительные ресурсы объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС. В процессе проектирования целесообразно выделять определенные ресурсы ЭВМ на оперативное обеспечение качества, повышение защищенности, безопасности и надежности функционирования. Допустимая величина и рациональное распределение ресурсов ЭВМ на отдельные методы улучшения определенных конструктивных характеристик качества ПС оказывают существенное влияние на достигаемые ими значения.
Обобщенными ресурсами ЖЦ проекта ПС являются доступные стоимость или совокупные трудовые, временные и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ. Эти характеристики непосредственно влияют практически на все показатели качества и определяют рентабельность покупки или создания заново конкретного программного продукта.
Это означает, что качество является относительным понятием, которое зависит от ресурсов и субъектов, осуществляющих его оценку с позиции эффективности использования, а также от состояния рынка соответствующей продукции, ее производителей и технологий. Ориентация на потребителей подразумевает анализ их нужд и определение возможностей рынка удовлетворить эти потребности. При этом следует учитывать рыночную конкуренцию двух видов: между поставщиками готовых к применению программных средств с фиксированным качеством и между разработчиками, способными обеспечить жизненный цикл ПС или его существенную часть, с характеристиками качества, требующимися конкретному заказчику. В последнем случае на требуемое качество могут оказывать влияние не только заказчик и непосредственные пользователи, но и различные посредники, организационные и торговые структуры, а также исполнители проекта.
В начале проектирования ПС всегда возникает задача оценивания ресурсов, которые необходимы и доступны для создания и обеспечения всего ЖЦ ПС, а также возможной экономической эффективности последующего применения комплекса программ по назначению при условии реализации требуемых характеристик качества. Экономическая эффективность и затраты имеют самостоятельное значение и методологию при анализе ЖЦ ПС. При планировании проектов программных средств часто инициатором разработки является разработчик-поставщик, который самостоятельно принимает все решения о проектировании за счет собственных ресурсов и предполагает возместить затраты при реализации программного продукта на рынке. В других случаях имеется определенный заказчик-потребитель, который способен задать основные цели, характеристики качества и обеспечить ресурсы для реализации проекта. Таким образом, при экономическом анализе ресурсов проектов ПС возможны два сценария (см. лекцию 5):
- создание и весь жизненный цикл комплекса программ и/или базы данных ориентируется разработчиком на массовое тиражирование и распространение на рынке, для заранее неизвестных покупателей-пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель-заказчик, который определяет и диктует основные требования, а также финансирует проект;
- разработка проекта ПС и/или БД предполагается поставщиком-разработчиком для конкретного потребителя-заказчика, задающего требования, который его финансирует, с определенным, необходимым ему тиражом и известной, ограниченной областью применения результатов разработки.
Источник: studfile.net
Ресурсы в программных проектах. Виды ресурсов
Для проектов ресурс – это объект проекта, которым можно управлять и который можно планировать. Чем же мы можем управлять, какие у нас есть свободные переменные, когда мы создаем программный проект.
Первый вид ресурсов – это люди (сотрудники), это самый главный ресурс, то чем мы можем управлять.
Следующий ресурс непосредственно связан с сотрудниками – это рабочее время. То время, которое отдельный сотрудник может выделять именно на участие в проекте.
Следующий ресурс – оборудование, которое может являться предметом управления.
Последний ресурс – это программное обеспечение.
А какое программное обеспечение? Т.е. все инструментальные средства, которые требуются для разработки. В тех случаях когда используется ограниченная или специальная лицензия на используемое ПО – это тоже может оказаться проблемой.
Поэтому – это все те ресурсы, которые нужно иметь в конкретном проекте в виду и которыми так или иначе необходимо управлять
Роли в программных проектах.
Роль – это конкретное воплощение или конкретное амплуа сотрудника в конкретном проекте в конкретное время. Т.е. один и тот же сотрудник может быть тестировщиком, может быть разработчиком, м.б. менеджером в одном проекте или в другом проекте или часть времени в каком-то проекте и т.д.
Совмещение ролей в программных проектах
Все ли роли могут совмещаться? Нет. Некоторые роли совмещать можно, некоторые роли совмещать нежелательно, некоторые роли совмещать совсем нельзя
Связи между ролями
Роли делятся на два класса – основные и дополнительные.
Основные роли – это роли, которые есть практически во всех проектах. А дополнительные включаются в проект по мере необходимости, если проект имеет какую-то определенную специфику.
Заказчик – это тот человек, который ставит задачу, платит деньги и в результате принимает готовую работу.
Планировщик ресурсов – это руководящее лицо компании разработчика, принимающее организационные и финансовые решения. В самой разработке участие не принимает, но управляет всей политикой компании и разработкой в частности.
Менеджер проекта – это менеджер среднего звена управления, который управляет какой-то конкретной группой, например, либо разработчиков, либо тестировщиков. Его задача принимать определенные управленческие решения по продвижению проекта.
Архитектор – человек ответственный за выработку проектных решений и создание архитектуры.
Руководитель команды (не всегда такая роль присутствует) – это выделенный разработчик (самый опытный), который руководит небольшой группой разработки.
Разработчик — тот кто собственно разрабатывает идеи придуманные архитектором.
Тестер или тестеровщик – человек, который тестирует созданные группами разработчиков артефакты, например, программы.
Разработчик документации – человек, который формирует необходимую программно-эксплуатационную документацию.
И еще две роли. Первая – это пользователь. Он не обязательно входит в команду разработки, он не обязательно является заказчиком, но это тот человек, который по сути использует систему в своей повседневной жизни.
Инженер группы поддержки – это человек, который уже на этапе выпуска проекта обеспечивает последнюю стадию ЖЦ и помогает, в том числе, пользователям работать с системой и улучшать систему.
Источник: cyberpedia.su
Ресурсы в приложениях .NET
Практически любое высококачественное приложение должно использовать ресурсы. Ресурс представляет собой любые неисполняемые данные, которые логически развертываются вместе с приложением. Ресурсы могут отображаться в приложении в виде сообщений об ошибках либо как часть интерфейса пользователя. Ресурсы могут содержать данные различных видов, включая символьные строки, изображения и объекты. (Для записи сохраняемых объектов в файл ресурсов объекты должны быть сериализуемыми.) Благодаря хранению данных в файле ресурсов сами данные можно изменять без повторной компиляции всего приложения. Это также позволяет хранить данные в одном месте и исключает необходимость в использовании жестко закодированных данных, которые хранятся в нескольких местах.
.NET обеспечивает всестороннюю поддержку для создания и локализации ресурсов. Кроме того, .NET поддерживает простую модель упаковки и развертывания локализованных ресурсов.
Создание и локализация ресурсов
В нелокализованном приложении файлы ресурсов можно использовать как хранилище для данных приложения, особенно для строк, которые в противном случае было бы необходимо жестко задавать в нескольких местах в исходном коде. Чаще всего ресурсы создаются в виде текстовых (txt) или XML-файлов (.resx), а для их компиляции в двоичные RESOURCES-файлы используется Resgen.exe (генератор файлов ресурсов). Эти файлы можно затем встроить в исполняемый файл приложения с помощью компилятора языка. Дополнительные сведения о создании ресурсов см. в разделе Создание файлов ресурсов.
Вы также можете локализовать ресурсы приложения для конкретных языков и региональных параметров. Это позволяет создавать локализованные (переведенные) версии приложений.
При разработке приложения, использующего локализованные ресурсы, необходимо назначить язык и региональные параметры, являющиеся нейтральными или резервными, языком и региональными параметрами, ресурсы которого используются в случае отсутствия подходящих ресурсов. Как правило, ресурсы нейтрального языка и региональных параметров хранятся в исполняемом файле приложения. Остальные ресурсы для отдельных языков и региональных параметров хранятся в автономных вспомогательных сборках. Дополнительные сведения см. в разделе Создание вспомогательных сборок.
Упаковка и развертывание ресурсов
Развертывание ресурсов локализованного приложения выполняется во вспомогательных сборках. Вспомогательная сборка содержит ресурсы для одного языка и региональных параметров; в ней нет никакого кода приложения. В модели развертывания вспомогательной сборки вы создаете приложение с одной сборкой по умолчанию (которая обычно является главной сборкой) и одной вспомогательной сборкой для каждого языка и региональных параметров, поддерживаемых приложением. Поскольку вспомогательные сборки не являются частью главной сборки, ресурсы, относящиеся к конкретному языку и региональным параметрам, можно легко заменять или обновлять, не заменяя главную сборку приложения.
Точно определите ресурсы, которые будут применяться в сборке ресурсов по умолчанию для приложения. Так как сборка по умолчанию является частью главной сборки, то при внесении в нее любых изменений потребуется замена главной сборки. Если ресурс по умолчанию не предоставлен, то в случае его поиска процессом использования резервных ресурсов будет создаваться исключение. В хорошо спроектированном приложении при использовании ресурсов исключения никогда не создаются.
Дополнительные сведения см. в статье Упаковка и развертывание ресурсов.
Извлечение ресурсов
Приложение во время выполнения загружает соответствующие локализованные ресурсы отдельно для каждого потока на основе языка и региональных параметров, которые заданы свойством CultureInfo.CurrentUICulture. Значение этого свойства формируется следующим образом:
- Присвоением свойству Thread.CurrentUICulture объекта CultureInfo, который представляет локализованные значения языка и региональных параметров.
- Если язык и региональные параметры не заданы явным образом, соответствующие значения по умолчанию для пользовательского интерфейса каждого потока извлекаются из свойства CultureInfo.DefaultThreadCurrentUICulture.
- Если язык и региональные параметры по умолчанию для пользовательского интерфейса в потоке не заданы явным образом, применяются язык и региональные параметры текущего пользователя на локальном компьютере. Реализации .NET, работающие в Windows, делают это путем вызова функции Windows GetUserDefaultUILanguage .
Дополнительные сведения об указании языка и региональных параметров для пользовательского интерфейса см. в разделах справки CultureInfo и CultureInfo.CurrentUICulture.
Ресурсы для текущего или определенного языка и региональных параметров пользовательского интерфейса можно получить с помощью класса System.Resources.ResourceManager. Хотя для получения ресурсов чаще всего используется класс ResourceManager, пространство имен System.Resources содержит дополнительные типы, которые можно использовать для получения ресурсов. Сюда входит следующее.
- Класс ResourceReader, который позволяет перечислять ресурсы, встроенные в сборку или хранящиеся в отдельном двоичном RESOURCES-файле. Это удобно, когда точные имена ресурсов, доступных во время выполнения, неизвестны.
- Класс ResXResourceReader, который позволяет получать ресурсы из XML-файла (.resx).
- Класс ResourceSet, который позволяет получать ресурсы для конкретного языка и региональных параметров без учета правил отката. Ресурсы могут храниться в сборке или отдельном двоичном RESOURCES-файле. Можно также разработать реализацию IResourceReader, которая позволит использовать класс ResourceSet для извлечения ресурсов из другого источника.
- Класс ResXResourceSet, который позволяет получить в память все элементы из XML-файла ресурсов.
См. также
- CultureInfo
- CultureInfo.CurrentUICulture
- Создание файлов ресурсов
- Упаковка и развертывание ресурсов
- Создание вспомогательных сборок
- Извлечение ресурсов
- Локализация в .NET
Источник: learn.microsoft.com