Fundamentos da Engenharia de Software

1. COCOMO * Componentes: . Marcus Vinícius Fernandes de Araújo. Thiago Siqueira Batista. Vanessa Batista de Melo Fundamentos da Engenharia de Software

2. IntroduçãoO método COCOMO (COnstructive COst MOdel) é um modelo construtivo de custo para o planejamento e execução de projetos de software. É um importante ingrediente para o gerenciamento daqueles, ou de linhas de negócio de software. Um modelo de custo fornece uma estrutura para a comunicação de decisões de negócio entre os envolvidos em um empreendimento  relacionado a software.Foi desenvolvido em 1981 por Barry Boehm, no livro Software Engineering Economics.O método foi derivado baseado em análises feitas sobre um conjunto que compreende 63 projetos, cobrindo áreas como: negócios, controle, científica, suporte e sistema operacional. Cocomo I

3. Modelos* COCOMO Básico: versão aplicável à grande maioria dos projetos de software, pequenos a médios em termos de tamanho. Entretanto, as medidas fornecidas pelo COCOMO Básico são limitadas, pois desconsideram alguns fatores como restrições de hardware, qualificação e experiência do pessoal, uso de modernas técnicas e ferramentas e outros atributos do projeto.* COCOMO Intermediário: adiciona fatores ao COCOMO Básico, proporcionando medidas mais precisas.* COCOMO Detalhado: apresenta técnicas para medir tanto em nível de módulo quanto em nível de subsistema e sistema, individualizando a cada fase do projeto os atributos de custo.

4. Tipos de Projetos de Software* Modo Orgânico (Convencional)* Modo Difuso ou Semidestacado* Modo Restrito ou Embutido

5. Equações do modelo básicoCoeficientes constantes encontrados por Boehm são utilizados nas equações do método COCOMO, e são escolhidos de acordo com o tipo de projeto que será analisado. As equações do COCOMO básico assumem a forma:E = a * KLOC b (esforço aplicado em pessoas-mês)D = c * E d (tempo de desenvolvimento, em meses)N = E/D (número de pessoas recomendadas)KLOC é o número estimado de linhas de código do projeto, em milhares.

6. Equações do modelo intermediárioO modelo básico é ampliado com a finalidade de levar em consideração um conjunto de “atributos direcionadores do custo” que podem ser agrupados em quatro grandes categorias:* Atributos do produto* Atributos do hardware* Atributos do pessoal* Atributos do projetoCada um dos atributos é classificado de acordo com uma escala de seis pontos que varia de “muito baixo” a “extremamente elevado”, em importância e valor. Baseando-se na classificação, um multiplicador de esforços é determinado a partir das tabelas publicadas por Boehm e o produto de todos os resultados de multiplicadores de esforços torna-se um fator de ajustamento de esforço (EAF). Os valores típicos do EAF variam de 0,9 a 1,4.A equação do COCOMO intermediário assume a forma:E = a * KLOC b * EAFonde E é o esforço aplicado em pessoas-mês e KLOC, o número estimado de linha de código para o projeto em milhares.

7. Qualidades* O COCOMO é uma métrica respeitável, muito bem embasada em experimentações, em derivações matemáticas e em tabelamentos de dados cruciais para que quaisquer profissionais da área de desenvolvimento possam realizar os cálculos necessários ao planejamento e à gestão da produção.* Provavelmente é a métrica que trata de maneira mais consistente e séria formas e fórmulas para o orçamento.* Há critérios muito bem definidos para a determinação dos níveis de influência do ambiente profissional e da capacidade produtiva dos profissionais envolvidos com o projeto.

8. Restrições* A métrica parte da premissa de que a dimensão do software já é conhecida e dada em milhares de instruções-fonte entregues. Não há qualquer menção, mesmo porque não se demonstrou qualquer preocupação com isto, de como realizar cálculos para chegar a tal valor. * Boehm e sua equipe de pesquisa delegam aos desenvolvedores de software a responsabilidade pela técnica ou método para tal dimensionamento.* Aos olhos dos desenvolvedores, o que resta, então, sugerir dimensionamento como resultado de julgamentos de especialistas ou uso de sólidos e confiáveis dados históricos que permitam inferências. Não é demais lembrar que tais práticas são discutíveis, quando não se tem organização eficaz e uma cultura bem formada sobre o assunto.

9. COCOMO IIIntroduçãoA utilização do COCOMO passou a requerer uma certa dose de adaptação, a fim de acomodar as dramáticas mudanças nos ciclos de vida do software, tecnologia, componentes, notações e culturas organizacionais. Então para melhor acomodar as tendências modernas da engenharia de software foi criado o COCOMO II. Que incorpora diversas melhorias testadas no campo, de modo a ampliar sua aplicabilidade e aperfeiçoar a acurácia de suas estimativas nas abordagens modernas para desenvolvimento de software.

10. Submodelos* COMPOSIÇÃO DA APLICAÇÃO* PRÉ-PROJETO* PÓS-ARQUITETURAO modelo COCOMO II ainda está em estudo, e suas informações só são apresentas em alguns artigos e congressos.Praticamente, não há, ainda, informações sólidas e consagradas sobre as estimativas possíveis e seus métodos para os submodelos Composição da Aplicação e Pré-Projeto. A quase totalidade das publicações encontrada enfoca o desenvolvimento e o aprimoramento do submodelo Pós-Arquitetura.

11. Fórmulas* Esforço E(HM) = a.Tamanho.b.Ci + Fre-eng* Prazo P(M) = j.Ek

12. Fatores de EquilíbrioPREC(Precedência em aplicações): de muito baixo (6,20) a extra alto (0,00)FLEX(Flexibilidade de desenvolvimento): de muito baixo (5,07) a extra alto (0,00)RELS(Resoluções de arquitetura ou riscos): de muito baixo (7,07) a extra alto (0,00)COE(Coesão da equipe de desenvolvimento): de muito baixo (5,48) a extra alto (0,00)PMAT(Maturidade do processo (nível CMM)): de muito baixo (7.80) a extra alto (0,00)

13. Fatores de Custo (Cost Drivers)1. Required Software Reliability (RELY)2. Data Base Size (DATA)3. Product Complexity (CPLX)4. Required Reusability (RUSE)5. Documentaion Match to life-cycle needs (DOCU)6. Execution Time Constraint (TIME)7. Main Storage Constraint (STOR)8. Platform Volatility (PVOL)9. Analyst Capability (ACAP)10. Programmer Capability (PCAP)11. Applications Experience (AEXP)12. Platform Experience (PEXP)13. Language and Tool Experience (LTEX)14. Personnel Continuity (PCON)15. Use of Software Tools (TOOL)16. MultiSite Development (SITE)17. Required Development Schedule (SCED)

14. CÁLCULO POR FASES O método ainda provê as distribuições de esforço e prazo calculados pelas fases de desenvolvimento da aplicação:* Planos e requisitos* Projeto do produto* Programação* Integração e teste

15. Qualidades* Além do bom embasamento da métrica, sua consistência, seriedade e critérios científicos (comentados para a versão de 1981), a evolução do COCOMO vem agregar pontos positivos na abertura que propõe ao tratamento de dados.* A nova versão se torna muito mais sensível às condições ambientais e às características profissionais e técnicas das organizações e equipes de desenvolvimento, permitindo que seus parâmetros sejam totalmente particularizados.* Fórmulas, fatores e direcionadores não são mais rígidos números, e sim dados dinâmicos, evoluindo ao sabor de pesquisas científicas sérias e de históricos particulares arquitetados, construídos e gerenciados com informações bem estruturadas.* A ampliação da gama de situações e circunstâncias analisadas para os devidos ajustes de valores calculados torna-a uma métrica de maior precisão, que pretende ser adequada ao desenvolvimento de software sob filosofias absolutamente modernas e futuristas.

16. Restrições* A métrica, apesar de já tecer considerações sobre o dimensionamento do produto em pontos de função, ainda parte da premissa de que a dimensão do software seja conhecida em milhares de linhas de código-fonte (KLOC). Toda e qualquer publicação, até então, está solidamente fixada na dimensão do software, tal qual era o COCOMO, em sua versão de 1981, e esta dimensão continua a exigir a responsabilidade de quem desenvolve e, portanto, aplica este modelo, pela técnica ou método para tal dimensionamento.* Muitos dos pontos apontados como salto evolutivo, ou como grande vantagem do novo método, estão obscuros, sem uma definição clara de como serão conquistados, por parte daqueles que a desenvolvem e pesquisam: há absoluta falta de dados sobre o submodelo Composição da Aplicação e pouca informação desenvolvida sobre o submodelo Pré-Projeto, isso além da insipiência de dados sobre a fórmula do esforço em reengenharia e a não definição de novos padrões de distribuição de esforços e prazos pelas fases de desenvolvimento do produto.

17. Vantagens e Desvantagens As vantagens do COCOMO são que o mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um componente individual de um projeto. Embora não mostrado aqui, o COCOMO pode também calcular a programação da manutenção anual. Além disso, O COCOMO pode fazer exame da vantagem de dados históricos e com estes dados uma constante da calibração pode ser calculada que faça as estimativas futuras mais exatas.  Uma das desvantagem é que esteve desenvolvido com o modelo cascata e, por conseguinte, as estimativas não puderam ser exatas para outros modelos tais como a programação espiral do modelo ou do xtreme.