Resumo Engenharia de Software

Capítulo 8 – Modelagem de Análise

Análise de Requisitos: Resulta na especificação das características operacionais do software, indicando a interface do software com outros elementos do sistema e estabelece restrições a que o software deve satisfazer. Permite ao engenheiro de software elaborar requisitos básicos e construir modelos que descrevam cenários, funções e comportamentos. Propiciam meios de avaliar a qualidade do software.

A modelagem deve atingir a 3 objetivos principais: 1 – Descrever o que o cliente exige; 2 – Estabelecer a base para a criação de um projeto de software; 3 – Definir um conjunto de requisitos que possam ser validados quando o software for construído.

Para a criação de um modelo de análise, o modelo deve focalizar os requisitos que são visíveis e funcionais no problema, na qual cada elemento deve contribuir para o entendimento global. O modelo deve ter valor a todos os interessados e deve ser o mais simples possível.

Análise de Domínio: é a identificação, análise e especificação dos requisitos em comuns de um domínio de aplicação específico, para reuso em vários projetos daquele domínio de aplicação.

8.2) Abordagens de Modelagem de Análise

Análise estruturada: Considera os dados e os processos que transformam os dados entidades separadas. Objetos de dados são modelados para que definam seus atributos e relacionamentos enquanto os Processos são modelados para que mostrem como eles transformam os dados à medida que os Objetos de dados fluem pelo sistema.

Análise Orientada a Objetos: Focaliza a definição de classes e o modo pelo qual elas colaboram umas com as outras para atender aos requisitos. Ex: UML e Processo Unificado.

8.3) Conceitos de Modelagem de Dados

Objeto de Dados: É uma representação de quase toda a informação composta que deve ser compreendida pelo software. Por informação composta queremos nos referir a algo com várias propriedades ou atributos diferente.

Atributo de Dados: Definem as propriedades de um objeto de dados e assumem uma das três diferentes características: 1 – Nomear um exemplo do objeto de dados; 2 – Descrever o exemplo; 3 – Fazer referência a outro exemplo. Um ou mais atributos pode ser definidos como Identificador, tornando-se uma chave.

Relacionamentos: Objetos de dados são conectadas uns com outros de diferentes modos através do entendimento do papel dos objetos e do contexto do software a ser construído.

Cardialidade e Modalidade: Cardialidade é a especificação do número de ocorrências de um objeto que pode ser relacionado ao número de ocorrências de outro objeto. A Modalidade de uma relação é 0 se não houver necessidade explícita de o relacionamento ocorrer ou é opcional, e é 1 quando o relacionamento é obrigatório.

8.4) Análise Orientada a Objetos

Em vez de examinarmos o problema usando um modelo convencional de entrada-processamento-saída ou um modelo derivado exclusivamente de estruturas de informação hierárquicas, a Análise Orientada a Objetos cria um modelo orientado a classes que se apóia no entendimentos dos conceitos de OO.

8.5) Modelagem Baseada em Cenário

Escrita de Casos de Uso: Capta as interações que ocorrem entre produtores e consumidores de informação e o sistema em si. O conceito de caso de uso descreve um cenário de uso específico em linguagem direta do ponto de vista de um ator definido, uma vez que saiba sobre o que escrever, quando escrever, o quão detalhado deve ser a descrição e como organizá-la.

Diagrama de Atividades: Complementa o caso de uso fornecendo uma representação gráfica do fluxo de interação em um cenário específico.

Diagrama de Raias: É uma variação do diagrama de atividades que permite ao modelador, representar o fluxo de atividades descrito pelo caso de uso e ao mesmo tempo, indicar que ator ou classe de análise é responsável pela ação descrita.

8.6) Modelagem Orientada a Fluxo

Embora o Diagrama de Fluxo de Dados(DFD) não sejam parte formal da UML, eles podem ser usados para complementar os diagramas de UML e fornecer visão adicional dos requisitos e fluxo do sistema. No DFD, os objetos de dados entram no software, são transformados por elementos de processamento e os objetos de dados resultantes saem do software.

À medida que o DFD é refinado em maior nível de detalhe, o analista realiza uma decomposição funcional implícita do sistema.

Modelagem de Fluxo de Controle: Utilizada para tratar uma grande classe de aplicações é orientada por eventos em vez de dados, produzem informações de controle em vem de relatórios ou imagens, e processam informação com grande preocupação em tempo e desempenho.

Especificação de Controle: Representa o comportamento do sistema como uma especificação de comportamento seqüencial ou como uma especificação de comportamento combinatória.

Especificação de Processo: Usada para descrever todos os processos do modelo de fluxo que aparecem no nível de refinamento final.

8.7) Modelagem Baseada em Classe

Classes de Análise: Classes podem ser identificadas como sendo uma Entidade Externa (que produzem ou consomem informações), Coisas (que são parte do domínio de informação do problema), Ocorrências (eventos que ocorrem durante o contexto), Papéis (funções desempenhadas por pessoas), Unidades Organizacionais (Unidades divididas por funções), Lugares (que estabelecem o contexto do problema) e Estruturas (que definem uma classe do problema).

Atributos: Os atributos definem a classe – que esclarecem o que a classe representa no contexto de espaço do problema.

Operações: Definem o comportamento de um objeto, sendo assim, uma operação deve ter ‘conhecimento’ da natureza e dos atributos e associações da classe.

Modelagem CRC (Classe-Responsabilidade-Colaboração): Fornece um meio simples para identificar e organizar as classes relevantes aos requisitos do sistema. Responsabilidades são os atributos e operações relevantes. Colaboradores são as classes necessárias para dar à classe informação necessárias para completar uma responsabilidade.

Associações: Quando duas classes de análise estão relacionadas entre si de algum modo, podendo criar um vínculo de dependência entre elas.

Pacote de Análise: Quando vários elementos do modelo de análise são empacotados como um agrupamento.

8.8) Modelo Comportamental

O modelo comportamental indica como o software responderá a eventos ou estímulos externos.

Eventos no Caso de Uso: Um caso de uso é examinado para encontrar pontos de troca de informações, para então, definir o evento gerado por essa troca.

Representação de Eventos: No contexto de modelagem comportamental, devem ser consideradas duas caracterizações de estados diferentes: 1 – o estado de cada classe à medida que o sistema realiza sua função; 2 – o estado do sistema, observado de fora, à medida que o sistema realiza sua função.

Diagrama de Estado para Classes de Análise: Representa os estados ativos de cada classe e os eventos que causam mudanças entre esses estados ativos.

Diagrama de Sequência: Indica como os eventos provocam transições de objeto para objeto.

Capítulo 15 – Métricas de Produto para Software

Usamos medidas para entender melhor os atributos dos modelos que criamos para avaliar a qualidade dos produtos ou sistemas submetidos à engenharia que construímos. Apesar de as métricas de produto para software de computador serem frequentemente não absolutas, elas nos dão um modo sistemático de avaliar qualidade com base em um conjunto de regras claramente definidas. Essas medidas de atributos internos dos produtos dão ao engenheiro de software uma indicação em tempo real da eficácia dos modelos de análise, projeto e código, da efetividade dos casos de teste e da qualidade global do software em construção.

15.1) Qualidade de Software

Qualidade de software: Satisfação de requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento documentadas e características implícitas que são esperadas em todo o software desenvolvido. Os requisitos de software é a base a partir da qual a qualidade é medida. Normas especificadas definem um conjunto de critérios que guiam o modo pelo qual o software é construído. O software deve atender também a requisitos implícitos (ex: facilidade de uso).

15.1.1) Fatores de Qualidade McCall

Os fatores que afetam a qualidade do software podem ser dividido em dois grandes grupos: 1 – Fatores que podem ser medidos diretamente (ex: defeito por ponto de função); 2 – Fatores que podem ser medidos apenas indiretamente (ex: usabilidade). McCall propõe uma categorização de fatores baseados em três aspectos importantes de um software: características operacionais, sua habilidade de passar por modificações e sua adaptabilidade a novos ambientes. Em alguns casos é impossível desenvolver medidas diretas desses fatores.

15.1.2) Fatores de Qualidade ISO 9126

A norma ISSO 9126 foi desenvolvida numa tentativa de identificar os atributos de qualidade para software de computador, identificando seis atributos-chave: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade. Os fatores ISSO não necessariamente se prestam a medidas diretas, mas fornece uma base valiosa para medidas indiretas e uma excelente lista de verificação para avaliação.

15.1.3) Transição para Visão Quantitativa

Em todos os casos, as métricas representam medidas indiretas, isto é, nunca realmente medimos a qualidade, mas uma manifestação da qualidade. O problema é definir a relação precisa entre a variável que é medida e a qualidade do software.

15.2) Um Arcabouço para Métricas de Produto

15.2.1) Métricas, Medidas e Indicadores

Medida: Fornece uma indicação quantitativa de extensão, quantidade, dimensão ou capacidade de algum atributo de um produto ou processo. Métrica: É o ato de determinar grau em que um sistema, componente ou processo possui um determinado atributo. Indicador: É uma métrica que fornece profundidade na visão do processo, projeto ou o produto em si.

15.2.2) O Desafio das Métricas Técnicas

O grande problema das medidas de complexidade propostos é que cada um adota um ponto de vista diferente sobre o que é complexidade e que atributos de um sistema levam à complexidade.

15.2.3) Princípios de Medição

O processo de medição por ser definido por cinco atividades: Formulação, Coleta, Análise, Interpretação e Realimentação. As métricas serão úteis quando este possui propriedades matemáticas desejáveis; quando a métrica diminui ou aumenta de acordo com a característica; quando a métrica mede o fator de interesse independente de outros fatores.

15.2.4) Medições de Software Orientadas a Objeto

Enfatiza a necessidade de estabelecer um objetivo explícito na medição; definir um conjunto de questões que precisam ser respondidas a fim de alcançar o objetivo e identificar métricas para responder a essas questões.

15.2.5) Os Atributos de Métricas de Software Efetivas

As métricas e as medidas que levam a elas devem ser: Simples e computáveis (fácil de aprender e sem gasto excessivo de tempo); Empíricas e Intuitivamente persuasivas (deve satisfazer às noções intuitivas do engenheiro); Consistentes e Objetivas (deve produzir resultados não ambíguos); Consistentes no uso de unidades e dimensões (cálculo matemático que não levem a unidades bizarras); Independente da linguagem de programação; Mecanismo efetivo para realimentação de alta qualidade (a métrica deve levar a um produto de maior qualidade).

15.2.6) A Paisagem da Métrica de Produto

Métricas para o modelo de análise: Enfatiza a entrega da funcionalidade, o tamanho do sistema e a qualidade da especificação.

Métricas para o modelo de projeto: Quantificam atributos do projeto de um modo que permita ao engenheiro de software avaliar a qualidade do projeto.

Métricas para Código-Fonte: Usadas para avaliar sua complexidade, manutenibilidade e testabilidade.

Métricas de teste: Ajuda o projeto de casos de teste efetivos e avaliam a eficácia do teste.

15.3) Métricas para o Modelo de Análise

15.3.1) Métricas Baseadas em Função (FP)

Pode ser usada como um meio para estimar o custo ou esforço necessário para projetar, codificar e testar o software; prever o número de erros e o número de componentes/linhas de código projetado no sistema.

15.3.2) Métricas de Qualidade de Especificação

Propõe uma lista de características que podem ser usadas para avaliar a qualidade do modelo de análise e da correspondente especificação de requisitos como especificidade, consistência, rastreabilidade, precisão, reusabilidade e etc.

15.4) Métricas para o Modelo de Projeto

15.4.1) Métricas de Projeto Arquitetural

Focalizam as características da arquitetura do programa com ênfase na efetividade dos módulos ou componentes da arquitetura.

15.4.2) Métricas para o Modelo de Projeto OO

Focalizam medições que podem ser aplicadas à classe e às características do projeto – localização, encapsulamento, herança - que tornam a classe singular.

15.4.3) Métricas Orientadas a Classe – O conjunto de Métricas CK

Como a classe é fundamental de um sistema OO, medidas e métricas para uma classe individual, para a hierarquia de classes e para as colaborações entre classes serão de grande valor para um engenheiro de software que precisa avaliar a qualidade do projeto.

15.4.4) Métricas Orientadas à Classe – O conjunto de Métricas MOOD

Propõe um conjunto de métricas para o projeto orientado a objetos que fornece indicadores quantitativos para as características do projeto OO.

15.4.5) Métricas Propostas por Lorenz e Kidd

Métricas baseadas em quatro categorias: tamanho (focaliza a contagem de atributos), herança (focalizam o modo pelo qual as operações são reusadas), aspectos internos (focalizam a coesão e código) e externos (examinam acoplamento e reuso).

15.4.6) Métricas de Projeto em Nível de Componente

Focalizam as características internas e incluem a medida dos “três C” – Coesão, Acoplamento e Complexidade.

15.4.7) Métricas Orientadas a Operação

Focalizam as operações baseado no tamanho médio de operação (número de linhas de código) e a complexidade da operação.

15.5) Métricas de Código-Fonte

A teoria de Halstead associou leis quantitativas ao desenvolvimento de software de computador, usando um conjunto de medidas primitivas que podem ser originadas após o código ser gerado, criando a métrica baseada no número de operadores e operandos do código.

15.6) Métricas para Teste

A maioria das métricas propostas focaliza o processo de teste, não as características do teste propriamente dito. As métricas de Halstead podem ser aplicadas para determinar o esforço do teste baseado no volume e nível do programa. As métricas de OO também podem ser aplicadas considerando encapsulamento e herança.

Capítulo 22 – Métricas de Processo e Projeto

Medição pode ser aplicada ao processo de software com o objetivo de melhorá-lo de forma contínua. Pode ser usada ao longo de um projeto de software para auxiliar na estimativa, no controle de qualidade, na avaliação de produtividade e no controle do projeto. Finalmente, medição pode ser usada pelos engenheiros de software para ajudar a avaliar a qualidade dos produtos do trabalho e auxiliar na tomada de decisões táticas à medida que o projeto evolui.

22.1) Métricas nos Domínios do Processo e do Projeto

Seu objetivo é fornecer um conjunto de indicadores de processo que leva a aperfeiçoamento do processo de software no longo prazo. Permite que o gerente de projeto avalie o estado de um processo em andamento; acompanhe riscos em potencial; descubra áreas-problema antes de se tornarem críticos; ajuste fluxo de trabalho ou tarefas e avalie a capacidade da equipe de projeto de controlar a qualidade.

22.1.1) Métricas de Processo e Aperfeiçoamento do Processo de Software

O processo situa-se no centro de um triângulo que liga três fatores com profunda influência na qualidade do software e no desempenho da organização. A capacidade e a motivação pessoal, a complexidade do produto e a tecnologia são esses três fatores. Além disso, esse triângulo se encontra dentro de um círculo de condições ambientais, que incluem o ambiente de desenvolvimento, condições de negócio e características do cliente.

22.1.2) Métricas de Projeto

Enquanto as métricas de processo de software são usadas com finalidade estratégica, métricas de projeto são táticas, com o objetivo de adaptar o fluxo de trabalho e as atividades técnicas do projeto. São usadas para minimizar o cronograma de desenvolvimento, fazendo ajustes necessários para evitar atrasos, problemas e riscos, além de avaliar a qualidade do produto durante a evolução.

22.2) Medição de Software

A medição de um software pode ser categorizada em: Medidas Diretas são todos os processos ligados diretamente no desenvolvimento do produto (linhas de código, tempo de execução); Medidas Indiretas: Inclui funcionalidades, qualidade, complexidade e etc.

22.2.1) Métricas Orientadas a Tamanho

Métricas orientadas a tamanho são originadas pela normalização das medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi produzido. Mas não são muito bem aceitas sendo que a principal controvérsia ocorre devido ao número de linhas, pois isso depende da linguagem de programação utilizada.

22.2.2) Métricas Orientadas à Função

A métrica orientada a função mais amplamente utilizada é a Pontos por Função, cujo cálculo é baseado em características do domínio de informação e complexidade do software. Existem controvérsias na sua utilização, uma vez que apesar de ser independente da linguagem de programação, o cálculo é baseado em dados subjetivos e as contagens no domínio da informação podem ser difíceis de coletar posteriormente.

22.2.4) Métricas Orientadas a Objeto

Métricas de projeto de software convencional (LOC ou FP) podem ser usadas para estimar projetos de software. No entanto, essas métricas não fornecem granularidade suficiente para os ajustes de cronograma e esforço que são necessários quando iteramos ao longo de um processo evolutivo ou incremental.

22.2.5) Métricas Orientadas a Casos de Uso

O caso de uso é definido logo no início do processo de software, permitindo que seja usado para estimativa antes que as atividades significativas de modelagem e construção sejam iniciadas. Casos de uso descrevem as funções e características visíveis ao usuário que são requisitos básicos de um sistema. É independente da linguagem de programação.

2.3) Métricas de Qualidade de Software

Métricas de qualidade de software focalizam o processo, projeto e produto. Desenvolvendo e analisando referências para métricas de qualidade, uma organização pode corrigir áreas do processo de software, que são as causas dos defeitos.

2.3.1) Medição de Qualidade

Apesar de existirem várias medidas de qualidade de software, a correção, manutebilidade, integridade e usabilidade fornecem indicadores úteis à equipe de software.

2.3.2) Eficiência na Remoção de Defeitos

Uma métrica de qualidade que fornece benefício tanto no nível de projeto quanto de processo é a eficiência na remoção de defeitos (DRE). É uma medida da capacidade de filtragem das atividades de controle e garantia de qualidade de software.

22.4) Integração de Métricas no Processo de Software

22.4.1) Argumentos Favoráveis a Métrica de Software

Para o estabelecimento de metas para aperfeiçoamento do processo, o estado atual do desenvolvimento do software deve ser conhecido. A medição é usada para estabelecer um referencial do processo a partir do qual as melhorias podem ser avaliadas. Usando a medição, os aspectos de desenvolver estimativas, produzir sistemas de alta qualidade e entregar os produtos dentro do prazo torna-se mais gerenciáveis. Coletar métricas de qualidade permite à organização ‘sintonizar’ seu processo de software para remover as causas de defeitos.

22.4.2) Estabelecimento de uma Referência

Para uma melhoria efetiva no processo os dados referenciais devem ser razoavelmente precisos; os dados devem ser coletados de tantos projetos quanto possível; as medições devem ser consistentes; as aplicações devem ser análogas ao trabalho que precisa ser estimado.

22.4.3) Coleta, Cálculo e Avaliação de Métricas

A coleta de dados exige uma investigação histórica de projetos anteriores para reconstruir os dados necessários. Uma vez coletadas essas medidas o cálculo e análise das métricas são possíveis. A avaliação as métricas focaliza as razões subjacentes dos resultados obtidos e produz um conjunto de indicadores que dão diretrizes ao projeto ou processo.

22.5) Métricas para Pequenas Organizações

Uma abordagem para as pequenas organizações é ‘torne simples’, ajuste às necessidades locais e certifique-se de que tem valor.

Capítulo 23 – Estimativa de Projetos de Software

23.1) Observações sobre Estimativa

As métricas de processo e projeto podem fornecer perspectiva histórica e insumo poderoso para a geração de estimativas quantitativas. A estimativa de recursos, de custo e de cronograma para o esforço de engenharia de software exige experiência, acesso a boas informações históricas e coragem para se empenhar em previsões quantitativas, quando a informação qualitativa é tudo que existe. O risco da estimativa é medido pelo grau de incerteza das estimativas quantitativas estabelecidas para recurso, custo e cronograma.

23.2) O Processo de Planejamento de Projeto

O objetivo do planejamento de projeto é fornecer um arcabouço que permita o gerente fazer estimativas razoáveis de recursos, custo e cronograma, além de tentar definir cenários correspondentes tanto do melhor quanto do pior caso, de modo que o comportamento do projeto possa ser delimitado.

23.3) Escopo e Viabilidade do Software

O escopo do software descreve as funções e características a serem entregues aos usuários finais, os dados que entram e saem, o “conteúdo” final é o resultado do uso do software e o desempenho, as restrições, as interfaces e a confiabilidade que limitam o sistema. As funções descritas no escopo são avaliadas e refinadas para fornecer mais detalhes antes do início da estimativa. Determinado o escopo, a equipe de software deve determinar se aquilo pode ser feito dentro das dimensões mencionadas.

23.4) Recursos

23.4.1) Recursos Humanos

A quantidade de pessoas necessárias para um projeto só pode ser determinada depois de ser feita uma estimativa do esforço de desenvolvimento. Após a avaliação do escopo e a seleção das aptidões necessárias, é feito a alocação e divisão dos recursos humanos.

23.4.2) Recursos de Software Reusáveis

Engenharia de software baseada em componentes enfatiza a reusabilidade, que são frequentemente negligenciados durante o planejamento, tornando-se foco de preocupação somente durante a fase de desenvolvimento de software.

23.4.3) Recursos de Ambiente

O ambiente que apóia o projeto de software incorpora elementos de hardware e software. O hardware fornece a plataforma que apóia as ferramentas (software) necessárias para produzir os produtos de trabalho, que são resultados de boas práticas de engenharia de software.

23.5) Estimativa do Projeto de Software

A estimativa de custo e de esforço nunca será uma ciência exata, pois depende de um demasiado número de variáveis – humanas, técnicas, ambientais, políticas – pode afetar o custo final do software e o esforço aplicado pra desenvolvê-lo. Existem algumas opções para conseguir estimativas:

1) Adiar a estimativa até o projeto estar o mais adiantado possível (não é muito viável, pois estimativas devem ser fornecidas logo)

2) Basear as estimativas em projetos semelhantes (pode funcionar bem se o projeto for bastante semelhante a esforços anteriores e as outras influências do projeto forem equivalentes)

3) Usar técnicas de decomposição relativamente simples4) Usar um ou mais modelos empíricos para estimativas

23.6) Técnicas de Decomposição

A estimativa de projetos de software é uma forma de solução de problemas, e muitas vezes o problema é muito complexo para ser considerado como um só. Para isso, o problema é decomposto, recaracterizando-o como um conjunto de problemas menores.

23.6.1) Dimensionamento do Software

A precisão da estimativa de um projeto de software depende de alguns fatores: 1 – O grau em que o planejador estimou adequadamente o tamanho do produto; 2 – A aptidão para traduzir a estimativa de tamanho em esforço humano; 3 – O grau com que o plano de projeto reflete a capacidade da equipe de software; 4 – A estabilidade dos requisitos do produto e do ambiente. O dimensionamento diz respeito ao tamanho do software, precisa ser quantificável e pode ser uma medida direta (LOC) ou indireta (FP).

23.6.2) Estimativa Baseada no Problema

Baseada em LOC: A declaração de escopo é preliminar, em que cada sentença teria que ser expandida para fornecer detalhes concretos e limites quantitativos.

Baseada em FP: Focaliza os valores do domínio da informação e vez das funções do software. É estimado as entradas, saídas, consultas, arquivos e interfaces externas para o software.

23.6.5) Estimativa Baseada em Processo

A técnica mais comum para estimar um projeto é basear a estimativa em um processo que será usado, ou seja, o processo é decomposto em um conjunto relativamente pequeno de tarefas e o esforço necessário para realizar cada tarefa é estimado.

23.6.7) Estimativas com Casos de Uso

Desenvolver estimativas com casos de uso é problemático, pois os casos de uso são descritos usando muitos formatos e estilos diferentes; representam uma visão externa (visão do usuário) e escrita em diferentes níveis de abstração; não tratam da complexidade e características das funções e não descrevem comportamentos complexos.

23.7) Modelos de Estimativas Empíricos

Os dados empíricos que apóiam a maioria dos modelos de estimativa são derivados de uma amostra limitada de projetos, por isso nenhum modelo de estimativa é adequado a todas as classes de software e a todos os ambientes de desenvolvimento. Utiliza fórmulas derivadas empiricamente para prever o esforço como função de LOC ou FP.

23.7.1) Estrutura dos Modelos de EstimativaUm modelo de estimativa típico é derivado usando análise de

regressão de dados coletados em projetos de software anteriores.23.7.2) O Modelo COCOMO II

O modelo COCOMO, que significa modelo construtivo de custo, tornou-se um dos modelos de estimativa de custo mais amplamente usados. Evoluiu para o modelo COCOMO II que requer informações de tamanho e usa pontos por objeto, usando a contagem da quantidade (1) de telas, de (2) relatórios e (3) componentes.

23.7.3) A Equação de SoftwareA equação de software é um modelo multiderivado, que considera

uma distribuição de esforço específica ao longo da vida de um projeto de desenvolvimento de software.

23.9) Técnicas Especializadas de Estimativa23.9.1) Estimativa para Desenvolvimento Ágil

Como os requisitos para um projeto ágil são definidos como um conjunto de cenários de usuário é possível desenvolver uma abordagem de estimativa que seja informal, mas ainda razoavelmente disciplinada e significativa no contexto de planejamento de projeto para cada incremento de software.

23.9.2) Estimativa para Projetos de Engenharia WebProjetos de engenharia web frequentemente adotam o modelo ágil de

processo. O volume de uma estimativa de WebApp é mais bem determinado pela coleta de medidas associadas com a aplicação, suas características de página web e características funcionais.

23.10) A Decisão e Fazer/ComprarOs passos envolvidos na aquisição do software são definidos pela criticalidade

do software e a ser adquirido pelo custo final. Na análise final, a decisão de fazer/comprar é tomada com base nas seguintes condições: (1) O produto de software vai ficar disponível antes do software desenvolvido inteiramente? (2) O custo de aquisição + personalização será menor que o custo de desenvolvimento do software? (3) O custo de apoio externo será menor que o custo de apoio interno? Para ajudar a chegar numa decisão existe técnicas estatísticas tais como a análise por arvore de decisão.

Capítulo 24 – Cronogramação

24.1) Conceitos Básicos

O atraso na entrega de um software ocorre por data de entrega irrealista, mudanças nos requisitos, subestimativa honesta da quantidade de esforço e recursos, riscos imprevisíveis ou previsíveis que não foram considerados, dificuldades técnicas e humanas, falha de comunicação e falha da gerência em reconhecer o atraso e tomar atitude para corrigi-lo.

24.2) Cronogramação de Projeto

Cronogramação de projeto é uma atividade que distribui o esforço estimado pela duração estimada do projeto, partilhando esses esforços por tarefas especificas de engenharia de software.

24.2.1) Princípios Básicos- Divisão do projeto em atividades e tarefas- Determinação das interdependências de cada atividade- Atribuição de tempo para cada tarefa- Definição da quantidade de membros pro projeto- Definição de um membro especifico para uma determinada tarefa- Definição de um resultado para cada tarefa- Cada tarefa deve ser associada a um marco de referência

24.2.2) O Relacionamento entre Pessoal e EsforçoQuando ocorre um atraso na entrega do software, tende-se a

aumentar a quantidade de pessoas nas ultimas fases do projeto, porém isso pode ter um efeito danoso, causando atrasos ainda maiores, uma vez que o novo pessoal precisa aprender sobre o sistema e os que vão treiná-los acabam perdendo mais tempo ainda.

24.3) Definição de um Conjunto de Tarefas para o Projeto de SoftwarePara desenvolver um cronograma de projeto, um conjunto de tarefas precisa

ser distribuído pelo prazo do projeto. O conjunto de tarefas vai variar dependendo do tipo de projeto e do grau de rigor com o qual a equipe decide fazer o seu trabalho. Principais tarefas:

1) Determinação de escopo inicial2) Planejamento conceitual preliminar3) Avaliação do risco da tecnologia4) Prova de Conceito5) Implementação Conceitual6) Reação do cliente

24.4) Definição de uma Rede de TarefasRede de Tarefas é uma representação gráfica do fluxo de tarefas de um

projeto. Como pode existir tarefas paralelas, deve-se determinar as dependências entre tarefas para garantir o progresso contínuo em direção ao término.

24.5) CronogramaçãoFerramentas de cronogramação: PERM e CPM.Ambas as ferramentas permitem ao planejador determinar o caminho critico,

estabelecer estimativas de tempo mais prováveis e calcular limites de tempo.24.5.1) Gráficos de Tempo

Gráfico de Tempo: É gerada após determinar e subdividir o conjunto de tarefas, duração e data de inicio para cada tarefa.

Tabelas de Projeto: Uma listagem tabular de todas as tarefas, de suas datas finais e iniciais, planejadas e reais e várias outras informações relacionadas.

24.5.1) Acompanhamento do Cronograma

O acompanhamento pode ser feito de várias formas:- Reuniões periódicas sobre o estado do projeto- Avaliação de resultados de todas as revisões- Determinação se os marcos de referência foram atingidos- Comparação da data de inicio real com a planejada- Reunião dos profissionais para obter sua avaliação do progresso

alcançado- Avaliação do progresso quantitativamente

24.6) Análise do Valor AgregadoO valor agregado é uma medida de progresso, que nos permite avaliar a

“porcentagem de execução” de um projeto usando análise quantitativa. Para isso, é feito o cálculo do custo orçado do trabalho realizado.