Программное обеспечение для алгоритмического управления проектами разработки ПО
SEER-SEM
Программное обеспечение SEER для управления проектами: оценка ресурсов разработки, анализ рисков на основе модели Softcost (1966-1980). Автоматизация оценки ПО.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Алгоритмическое программное обеспечение для управления проектами
Algorithmic project management software
SEER for Software (SEER SEM) — это приложение для управления проектами, предназначенное для оценки ресурсов, необходимых при разработке программного обеспечения.
SEER for Software (SEER SEM) is a project management application used to estimate resources required for software development.
История
1966 Модель корпорации System Development Corporation, основанная на регрессионном анализе. В 1980 году Дон Рейфер и Дэн Галорат опубликовали работу, которая послужила толчком к созданию модели JPL Softcost. Эта модель, являясь одним из первых примеров оценки программного обеспечения, позволяет автоматизировать проведение анализа рисков. Позднее Softcost был коммерциализирован компанией Reifer Consultants. В 1984 году Computer Economics JS 2 и Галорат разработали Систему 3 на основе модели Дженсена. Модель Дженсена послужила вдохновением для System 3, а другие моделирующие системы, такие как COCOMO Барри Боэма и ранние работы Doty Associates, можно рассматривать как прямых и косвенных предшественников программного обеспечения, которое Галорат разработал в конце 1980-х годов. В 1988 году компания Galorath Incorporated начала работу над первоначальной версией SEER SEM.
1966 System Development Corporation Model based on regressions. 1980 Don Reifer and Dan Galorath paper which prompted the building of the JPL Softcost model. This model, an early example of software estimation, allows for automated and performed risk analysis. Softcost was later made a commercial product by Reifer Consultants. 1984 Computer Economics JS 2 and Galorath Designed System 3 based on the Jensen model. The Jensen inspired System 3, and other modeling systems like Barry Boehm's COCOMO and early works by the Doty Associates can be seen as direct and indirect contributors to the software suite that would be developed by Galorath in the late 1980s. In 1988, Galorath Incorporated began work on the initial version of SEER SEM.
Группа моделей
SEER для программного обеспечения (SEER SEM) состоит из группы моделей, работающих совместно для предоставления оценок трудозатрат, продолжительности, укомплектованности штатом и количества дефектов. Эти модели можно кратко описать вопросами, на которые они отвечают:
SEER for Software (SEER SEM) is composed of a group of models working together to provide estimates of effort, duration, staffing, and defects. These models can be briefly described by the questions they answer:
Определение размера. Каков размер оцениваемого программного проекта (строки кода, функциональные точки, сценарии использования и т.д.)? Технологии. Какова потенциальная производительность разработчиков (компетенции, инструменты, практики и т.д.)? Расчет трудозатрат и сроков. Сколько трудозатрат и времени потребуется для завершения проекта? Расчет трудозатрат/сроков с ограничениями. Как изменится ожидаемый результат проекта при применении ограничений по срокам и численности персонала? Распределение задач и трудовых ресурсов. Как следует распределять задачи и трудовые ресурсы в оценке? Расчет стоимости. Какова будет стоимость проекта, исходя из ожидаемых трудозатрат, продолжительности и распределения трудовых ресурсов? Расчет дефектов. Каково ожидаемое объективное качество поставляемого программного обеспечения, учитывая тип продукта, продолжительность проекта и другую информацию? Расчет трудозатрат на сопровождение. Сколько трудозатрат потребуется для надлежащего обслуживания и обновления развернутой системы программного обеспечения? Отслеживание прогресса. Как продвигается проект и каким будет его итог? А также как проводить перепланирование. Обоснованность. Возможно ли реализовать данную разработку, исходя из используемых технологий?
Sizing. How large is the software project being estimated (Lines of Code, Function Points, Use Cases, etc.) Technology. What is the possible productivity of the developers (capabilities, tools, practices, etc.) Effort and Schedule Calculation. What amount of effort and time are required to complete the project? Constrained Effort/Schedule Calculation. How does the expected project outcome change when schedule and staffing constraints are applied? Activity and Labor Allocation. How should activities and labor be allocated into the estimate? Cost Calculation. Given expected effort, duration, and the labor allocation, how much will the project cost? Defect Calculation. Given product type, project duration, and other information, what is the expected, objective quality of the delivered software? Maintenance Effort Calculation. How much effort will be required to adequately maintain and upgrade a fielded software system? Progress. How is the project progressing and where will it end up. Also how to replan. Validity. Is this development achievable based on the technology involved?
Размер программного обеспечения
Размер программного обеспечения является ключевым входным параметром для любой оценочной модели и для большинства параметрических моделей программного обеспечения. Поддерживаемые метрики размера включают в себя строки исходного кода (SLOC), функциональные точки, функционально-ориентированное определение размера (FBS) и ряд других показателей. Они преобразуются для внутреннего использования в эффективный размер, который служит единой мерой внутри модели и позволяет комбинировать новый, повторно используемый и даже готовый коммерческий код для комплексного анализа процесса разработки программного обеспечения. Общая формула для эффективного размера:
Software size is a key input to any estimating model and across most software parametric models. Supported sizing metrics include source lines of code (SLOC), function points, function based sizing (FBS) and a range of other measures. They are translated for internal use into effective size is a form of common currency within the model and enables new, reused, and even commercial off the shelf code to be mixed for an integrated analysis of the software development process. The generic calculation for is:
Как указано, эффективный размер увеличивается прямо пропорционально объему разрабатываемого нового программного обеспечения. Эффективный размер увеличивается в меньшей степени при повторном использовании существующего кода в проекте. Степень этого увеличения определяется объемом работ по доработке (перепроектирование, перереализация и повторное тестирование), необходимых для повторного использования кода.
As indicated, increases in direct proportion to the amount of new software being developed. increases by a lesser amount as preexisting code is reused in a project. The extent of this increase is governed by the amount of rework (redesign, re implementation, and retest) required to reuse the code.