ESAB – Pós-graduação em Engenharia de Sistemas Módulo: Tópicos Avançados de Engenharia de Software
RESUMO UNIDADE 1: SWEBOK
Engenharia de Software → área de interesse focada na criação e manutenção de aplicações de software, através de tecnologias e práticas da ciência da computação, gerência de projetos, engenharia, entre outros.
Objetivos do SWEBOK:
• visão consistente da engenharia de software;
• definir as fronteiras entre a engenharia de software e as outras áreas de interesse;
• caracterizar o conteúdo da disciplina de engenharia de software e classificá-la em tópicos; • prover base para desenvolvimento curricular, certificação individual e licenciamento de
material.
SWEBOK está divido em partes, as Áreas de Conhecimento (são dez):
• Requisitos de Software → levantamento, análise e validação para atender a expectativa do cliente;
• Design de Software → transformação de requisitos em termos relevantes ao domínio do problema, explicando como solucionar os aspectos do problema relacionados com o software;
• Construção de Software → codificação, validação inicial e teste unitário;
• Teste de Software → valida o comportamento dinâmico do programa através de casos de teste;
• Manutenção de Software → atividades de suporte (antes e depois) da entrega; • Gerência de Configuração de Software → identifica a configuração do sistema para
controlar suas mudanças e manter sua integridade e rastreabilidade durante o ciclo de vida; • Gerência de Engenharia de Software → cuida dos projetos de desenvolvimento de software; • Processo de Engenharia de Software → define, implementa, mede, gerencia e melhora o
processo;
• Métodos e Ferramentas de Engenharia de Software → para auxiliar e sistematizar o desenvolvimento e manutenção;
• Qualidade de Software → do produto (software) e do processo de desenvolvimento. UNIDADE 2: Estilos arquiteturais importantes da Engenharia de Software
• Arquitetura Centrada nos Dados (Repositório): tem a base central de dados, acessada pelos componentes (clientes e Ks – Knowledge Source) que executam operações nela. Os
componentes não possuem comunicação entre si;
• Arquitetura de Fluxo de Dados: os dados de entrada são transformados através de componentes computacionais em dados de saída;
• Arquitetura de Chamada e Retorno: muito usada na análise estruturada, caracteriza-se por um programa inicial (principal) que chama outros programas (sub-rotinas) em sequência preestabelecida (ao terminar a execução, o controle volta ao programa principal);
• Arquitetura Orientada a Objetos: elementos do sistema (dados e operações) são encapsulados em objetos;
• Arquitetura em Camadas: camada interna possui operações de baixo nível, as camadas intermediárias fornecem serviços. Esta arquitetura possui maior facilidade para reuso.
UNIDADE 3: Engenharia de Proteção
Foco na implementação de sistemas seguros, mantendo a disponibilidade, confidencialidade e integridade do sistema e seus dados.
Algumas atividades que devem ser observadas: • gerenciamento de usuários e permissões;
• configuração de software e middleware adequada; • atualização regular do software/middleware;
• monitoramento do sistema com planos de contingência;
• arquitetura em camadas com diferentes níveis de proteção para as diferentes camadas do sistema, por exemplo:
• Proteção no Nível de Plataforma (identificação do usuário);
• Proteção no Nível da Aplicação (permissões do usuário dentro da aplicação); • Proteção no Nível de Registro (acesso e operações em registros de dados). UNIDADE 4: Diretrizes para um projeto seguro de software
• Basear as decisões de proteção em uma política explícita (a política define “o que”, não “o como”);
• Evitar um ponto único de falha (evitar ter um mecanismo único de proteção - “defesa em profundidade” - empregando técnicas distintas);
• Falhar de maneira protegida (fail-safe);
• Equilibrar proteção e facilidade de uso (a proteção não pode deixar o sistema excessivamente complexo);
• Tomar cuidado com a Engenharia Social;
• Redundância (mais de uma versão do software e/ou dados) e diversidade(versões diferentes baseadas em plataformas e/ou tecnologias diferentes) para redução de riscos;
• Validar todas as entradas (para evitar entradas inesperadas que causem comportamentos imprevistos);
• Compartilhar os ativos (organizar a informação de modo a fornecer apenas o que o usuário necessita);
• Projetar para implantação (o sistema deve ser configurado corretamente ao ser implantado); • Projetar para capacidade de recuperação (voltar a um estado seguro).
UNIDADE 5: Apresentar aspectos importantes do projeto da interface com usuário
Não é comum contratar especialistas pra desenvolver a interface com usuário, então normalmente os Engenheiros de Software é que tem que lidar com isso.
Tipos de interface:
• entre componentes de software;
• entre o software e outras entidades externas;
• interface entre o ser humano e o computador (IHC), que pode ser: • Interface Gráfica de Usuário (GUI);
• Interface Web de usuário; • Interface de Linha de Comando; • Interface tátil.
Regras de ouro da Interface com usuário: • Coloque o usuário no controle:
• Defina os modos de interação; • Proporcione interação flexível; • Permita a interrupção e o desfazer;
• Simplifique a interação e permita a personalização; • Esconda detalhes técnicos;
• Faça a interação direta com os objetos na tela. • Reduza a carga de memória do usuário:
• Reduza a necessidade de memória de curto prazo; • Estabeleça defaults significativos;
• Defina atalhos intuitivos;
• Interface análoga ao mundo real; • Revele informações progressivamente . • Faça a interface consistente:
• Situe o usuário dentro do contexto maior; • Mantenha consistência;
• Se modelos anteriores foram significativos p/ os usuários não modificar. O projeto de uma interface de usuário pode ser feito em paralelo com outras atividades de desenvolvimento do projeto e muitas vezes está integrado a ele.
As principais atividades no processo de desenvolvimento de interface:
• Análise de usuário → compreender quais as tarefas que os usuários realizam e como eles as realizam (e como interagem com o sistema);
• Prototipação do sistema → o processo de desenvolvimento de interface é interativo, então é útil o uso de protótipos para validação do usuário;
• Avaliação da interface → além do feedback do usuário, também deve existir uma avaliação formal para coletar informações sobre a experiência do usuário com a interface.
UNIDADE 6: Gerenciamento de Pessoal
O aumento do número de pessoas em uma equipe não se traduz necessariamente em aumento de produtividade (uma solução é dividir a equipe em grupos menores, especializados).
Um problema muito comum é a comunicação entre os membros. As ferramentas atuais (e-mail, chat, conferências, etc) ajudam muito para uma comunicação mais eficiente. A boa comunicação mantém a coesão do grupo e motivação. Os fatores que influenciam a eficiência da comunicação são:
• Tamanho do grupo → em grupos com 7 ou 8 elementos, é provável que algumas pessoas raramente (ou nunca) se comuniquem;
• Estrutura do grupo → membros de grupos estruturados informalmente se comunicam mais do que membros de grupos com estrutura formal e hierárquica (que normalmente se comunicam através dos gerentes);
• Composição do grupo → envolve a personalidade dos membros do grupo, que podem entrar em conflito;
• Ambiente físico de trabalho → organização do local de trabalho tem importância.
Arquiteturas planas e abertas não são populares nem produtivas. Alguns fatores relevantes ao ambiente físico de trabalho (estudo de McCue – 1978):
• Privacidade → programadores rendem melhor em ambientes fechados; • Consciência externa → pessoas preferem luz natural e com visão do exterior; • Personalização → poder personalizar seu ambiente de trabalho de acordo com as
práticas individuais é importante.
Gerente de projeto → deve motivar membros de sua equipe. As necessidades que tem importância na motivação são: necessidade de satisfação social, autoestima e autorrealização.
UNIDADE 7: Modelos de Gerenciamento de Pessoal
• Modelo de Maturidade de Capacitação de Pessoal (P-Cmm) → é um framework de
aprimoramento para a maneira pela qual uma organização gerencia seu patrimônio humano (estabelece a necessidade de reconhecer a importância das pessoas – motivação,
reconhecimento, padronização e aprimoramento de boas práticas). É um modelo de 5 níveis (assim como o CMM):
1. Inicial → práticas de gestão de pessoas inconsistentes;
2. Gerenciado → gestores gerenciam e desenvolvem seu pessoal;
3. Definido → Desenvolvimento das competências alinhadas aos objetivos e estratégias do negócio;
4. Previsível → gestão quantitativa do desempenho;
5. Em otimização → evolução da capacidade da organização e sua força de trabalho. • PSP – Personal Software Process → focado em engenheiros de software individuais. Foi desenvolvido para guiar como planejar e desenvolver módulos de software (ou pequenas aplicações). Ele favorece a organização na medida em que melhora o trabalho individual. Objetivos principais:
• Melhorar as estimativas;
• Melhorar o planejamento e acompanhamento dos cronogramas; • Proteger contra o excesso de compromissos;
• Criar um comprometimento pessoal para a qualidade;
• Envolvimento contínuo do engenheiro na melhoria contínua do processo;
Estudos mostraram que a implantação do PSP melhorou em 75% a estimativa de esforço, em 150% a estimativa de tamanho (diminuiu a tendência de subestimar estes itens); além disso, a qualidade do produto melhorou sem impactos no trabalho individual (ou seja, houve aumento de
produtividade).
UNIDADE 8: Gerenciamento da Qualidade
Apresenta a importância da qualidade do software (e como tem ganhado destaque nos últimos 15 anos). Alguns problemas envolvidos neste tema:
• embora a especificação seja orientada para o que o cliente deseja, a organização pode ter seus próprios requisitos (ex. Facilidade de manutenção), não incluídos na especificação; • nem sempre sabemos especificar características de qualidade de forma não-ambígua; • é difícil descrever completamente as características do software.
O SWEBOK trata da Qualidade do Software, dividindo-a em 3 tópicos: 1 Fundamentos da Qualidade de Software
1.1 Cultura ética de Engenharia de Software 1.2 Valores e Custos da Qualidade
1.3 Modelos e Características de Qualidade 1.4 Melhoria de Qualidade
2 Gerência do Processo de Qualidade de Software 2.1 Garantia de Qualidade de Software 2.2 Verificação e Validação
2.3 Revisões e Auditorias 3 Considerações Práticas
3.1 Requisitos de Qualidade para Aplicações 3.2 Caracterização de Defeitos
3.3 Técnicas de Gerência de Qualidade de Software 3.4 Medidas de Qualidade de Software
*sistemas menores podem adotar uma abordagem mais informal.
Atividades principais de gerenciamento de qualidade de software para sistemas maiores:
• Garantia da Qualidade → estabelecer framework de procedimentos e padrões que conduzem a um software de qualidade;
• Planejamento de Qualidade → seleção de procedimentos e padrões do framework aplicáveis a um projeto específico;
• Controle da Qualidade → definição e aprovação de processos que assegurem que a equipe de desenvolvimento tenha seguido os procedimentos adotados.
Tipos de padrões que são parte do processo de Garantia da Qualidade:
• Padrões de Produto → se aplicam especificamente ao software, padrões de documentação (requisitos, definição de classes), codificação;
• Padrões de Processo → processos que devem ser seguidos durante o desenvolvimento de software (especificação, projeto e validação), com a descrição dos documentos que devem ser escritos ao longo do processo.
UNIDADE 9: Padrão de Qualidade – ISO 9000
Estabelece princípios de qualidade aplicáveis a quaisquer organizações, e pode ser usado para software. Descreve os aspectos do processo de qualidade, padrões e procedimentos organizacionais que a empresa deve definir.
Indica que a empresa definiu processos que ela julga necessários para assegurar a qualidade de seu produto e seguiu estes processos para a construção do produto.
Padrões de documentação:
• Padrões de Processo de Documentação: definem o processo a ser seguido para a produção de documentos;
• Padrões de Documentos: estrutura e apresentação física dos documentos;
• Padrões de Intercâmbio de documentos: asseguram que as cópias eletrônicas de documentos sejam compatíveis.
UNIDADE 10: Desenvolvimento de Sistemas Críticos
Sistemas dito críticos são sistemas que necessitam de um altíssimo grau de confiabilidade. Algumas abordagens que seguem nesta direção (para desenvolvimento de software) são:
• Prevenção de defeitos → o processo de projeto e implementação deve contemplar técnicas que minimizem o número de defeitos de um programa;
• Detecção de Defeitos → processos de verificação e validação são projetados para descobrir e remover defeitos antes da implantação do sistema;
• Tolerância a Defeitos → sistema deve ser projetado de forma que os defeitos ou
comportamentos inesperados do sistema em execução, sejam detectados e tratados para que a falha do sistema não ocorra.
Alguns detalhes adicionais sobre confiabilidade:
• redundância → para recuperação rápida em caso de falha;
• diversidade → voltado à segurança, variedade de mecanismos de proteção.
projetos, que devem ser bem rigorosos para minimizar isso), então podem ser adotados dependendo do caso, pela empresa.
UNIDADE 11: Desenvolvimento de Sistemas Críticos (continuação) Práticas que visam diminuir os defeitos em sistemas de software:
• Processos confiáveis → com atividades de validação e verificação apropriadas; • Gerenciamento de Qualidade → padrões de desenvolvimento e projeto devem ser
estabelecidos, bem como procedimentos para verificação se os padrões foram seguidos; • Especificação formal e precisa → evita interpretação errada (no caso de uma especificação
ambígua);
• Verificação Estática → uso de analisadores para encontrar possíveis problemas no código; • Tipagem forte → em geral, as linguagens mais usadas já possuem esta característica;
• Programação Segura → evitar construções muito complexas (mais sujeitas a erros), sempre que possível;
• Informações Protegidas → encapsulamento, uso de interfaces, basicamente proteção a processos internos dos elementos de software.
UNIDADE 12: Tolerância a Defeitos
Embora a “programação defensiva” (ações de verificação e recuperação de software) seja uma prática recomendada, ela não resolve todos os problemas.
Em sistemas críticos, é necessária uma arquitetura de hardware específica, projetada para ter tolerância a defeitos, normalmente com o uso de redundância (um exemplo é a Redundância Modular Tripla – 3 ou mais saídas de um módulo passam por um comparador que descarta um valor se estiver diferente dos demais, retirando a unidade de serviço, se necessário).
*a abordagem de tolerância a defeitos se baseia na premissa de que a maioria das falhas ocorre por defeitos em componentes ao invés de ser um problema de projeto. Com todas as unidades operando de acordo com a especificação, há baixa probabilidade de falha simultânea em componentes de todas as unidades de hardware.
Componentes projetados e desenvolvidos por equipes e fábricas diferentes, dentro de uma especificação comum, também reduz a probabilidade de falha simultânea (mais difícil que duas equipes diferentes cometam os mesmos erros).
Abordagens para tolerância a defeitos de software:
• Programação em N-Versões → a partir de uma especificação comum, um software é desenvolvido em N-Versões em paralelo, por equipes diferentes. As saídas são comparadas em sistema de votação, rejeitando saídas inconsistentes. Devem ser produzidas ao menos 3 versões de sistema. Exemplos de uso: Sinalização de ferrovias, sistemas de aviação e sistemas de proteção de reatores;
• Blocos de Recuperação → cada componente inclui um teste para verificar sucesso de execução e também um código alternativo para permitir que o sistema repita o
processamento se o teste detectar uma falha (interpretações diferentes de uma mesma especificação).
UNIDADE 13: Estratégias de Teste de Software
Deve ser flexível o suficiente para promover uma abordagem do software sob medida, porém rígida o suficiente para promover planejamento e acompanhamento gerencial ao longo do projeto.
Conflito de interesses → desenvolvedor testar o próprio software (quer mostrar sempre resultados positivos).
• Desenvolvedor → testes de unidade e de integração;
• Grupo Independente de Teste (ITG) → faz a homologação, realizando testes de sistema, evitando o conflito de interesses (justamente por ser independente).
• Usuários fazem testes alfa e beta.
Preferencialmente, membros do ITG devem fazer parte da equipe de desenvolvimento mas não devem se envolver no processo de desenvolvimento e também devem conhecer o domínio do negócio (o ITG pode pertencer à equipe de garantia de qualidade de software).
UNIDADE 14: Espiral de testes de Software
Representa a estratégia de teste de software, partindo dos elementos menores até o sistema completo:
• Teste de Unidade → Teste de Integração → Teste de Validação → Teste de Sistema • Teste de Unidade → se concentra em componente de software (na implementação); • Teste de Integração → foco no projeto e na construção da arquitetura de software; • Teste de Validação → valida os requisitos estabelecidos em contraste com o que foi
entregue;
• Teste de Sistema → verificação geral do software e dos outros elementos do sistema. * essencialmente, teste de software orientado a objetos segue a filosofia aplicada a arquiteturas convencionais (difere um pouco na abordagem, como será visto mais adiante).
UNIDADE 15: Testes de caixa-preta e Caixa-branca
• Teste de caixa-preta: testes conduzidos na interface do sistema (teste funcional). Examina aspectos fundamentais do sistema, sem preocupação com a estrutura interna dele;
• Teste de caixa-branca: exame rigoroso dos detalhes de procedimentos e caminhos lógicos internos do software e colaborações entre componentes (teste estrutural).
Testes de caixa-preta são recomendados para poder testar a interface do sistema, aplicável em qualquer fase de testes.
Testes de caixa-branca devem ser realizados para um número limitado de caminhos lógicos importantes dentro do sistema, e normalmente se aplica às fases de Teste de Unidade e Teste de Integração.
Esta abordagem está sendo modificada para as 3 técnicas abaixo:
• Baseadas em especificação → casos de teste derivados de modelos formais ou informais que são utilizados na especificação do problema;
• Baseadas em estrutura → casos de teste são derivados de informações sobre como o software foi construído (p.ex. Código e modelagem);
• Baseadas em experiência → casos de teste são derivados da experiência e conhecimento de pessoas sobre efeitos prováveis, uso e ambiente do sistema.
UNIDADE 16: Teste orientado a objetos
Em função da arquitetura de software orientada a objetos produzir subsistemas de elementos que colaboram entre si, um teste orientado a objetos começa com a análise e revisão dos modelos. A seguir, uma série de testes são projetados para validar as operações de classes e examinar erros
nas colaborações entre as classes.
Testes baseados em uso são realizados quando as classes são integradas para formar um subsistema e casos de uso são usados para descobrir erros no nível de validação do software.
A metodologia de teste de caixa-preta pode ser aplicada sem problemas (o teste de caixa-branca não é tão eficiente neste caso, e pode ser substituído pelos testes no nível de classe).
Teste baseado em erro: o testador procura por erros plausíveis, ou seja, aspectos da implementação do sistema que podem resultar em defeitos. Depende do conhecimento dos testadores em definir o que é um erro plausível (se os modelos de análise e projeto puderem fornecer conhecimento mais aprofundado do que é provável dar errado, essa abordagem torna-se bastante eficiente). Neste contexto, 3 tipos de erro podem ser encontrados:
• Resultado inesperado;
• Uso da operação/mensagem errada; • Invocação incorreta.
UNIDADE 17: Projeto de Software de Tempo Real
Sistemas de Tempo Real (STR) → sistema de software cujo funcionamento depende dos resultados produzidos pelo sistema e do tempo em que estes resultados são produzidos.
Categorias:
• Leve (Classe A) → é aquele cuja operação será degradada caso os resultados não sejam produzidos de acordo com o timing especificado (o tempo de resposta variável é
admissível);
• Rígido (Classe B) → a operação será incorreta se os resultados não estiverem de acordo com a especificação de timing (a resposta deve ser fornecida num tempo finito e especificado). STR → necessita de mecanismos de gerenciamento de atividades, que as classifica de acordo com a prioridade.
Sistemas Operacionais de Tempo Real (RTOS) → usado em sistemas embutidos (embedded), dedicados a tarefas específicas. Enquanto um Sistema Operacional tradicional controla o sistema na inicialização e o lançamento das aplicações, além de ter um certo controle de segurança para erros de aplicativos, em RTOSs a aplicação é geralmente 'likeditada' junto com o sistema operacional e lançada na inicialização; e geralmente, RTOSs não verificam erros de aplicação.
Microcontrolador → usados em sistemas para propósitos específicos;
Microprocessador → usado em computadores de propósito geral, fazendo uso em alguns casos dos microcontroladores;
UNIDADE 18: Engenharia de Software Orientada a Serviços
SOA (Service-Oriented Architectures) → voltados ao desenvolvimento de sistemas distribuídos onde os componentes do sistema são serviços dedicados, que podem ser executados em
computadores diferentes, apoiados em protocolos padronizados para troca de comunicação e informações.
Serviço → componente de software reusável, não firmemente acoplável, que engloba funcionalidade discreta que pode ser distribuída e acessada por meio de programas (p. ex. WebService).
O processo exige que os provedores de serviços registrem informações em um registro central para que os clientes possam determinar quais serviços são necessários a cada caso e utilizá-los a partir de
um contrato de serviço.
Principais padrões de arquitetura orientada a serviços:
• SOAP (Simple Object Access Protocol) → padrão de troca de mensagens que dá suporte à comunicação entre serviços (define componentes principais e opcionais das mensagens); • WSDL (Web Service Definition Language) → estabelece o meio pelo qual os provedores de
serviços devem definir a interface do serviço;
• UDDI (Universal Description, Discovery and Integration) → define os componentes de uma especificação de serviços, usada para descobrir a existência de um serviço (incluem
informações sobre o provedor de serviços, serviços fornecidos, a localização da descrição desses serviços.
UNIDADE 19: Engenharia de Serviços
É o processo de desenvolvimento para reuso nas aplicações orientadas a serviços.
Serviço → abstração reusável, portanto o projeto tem que ser robusto, confiável e interoperável. Estágios no processo de engenharia de serviços:
• identificação do serviço candidato → possíveis serviços que poderiam ser implementados e seus requisitos (devem complementar os processos de negócio, logo, estes precisam ser compreendidos para apoiar o projeto dos serviços) ;
• projeto do serviço → lógica e interfaces WSDL; • implementação e implantação do serviço. Tipos de serviços:
• Serviço de Utilidades → funcionalidades gerais que podem ser usadas por diferentes processos de negócio;
• Serviço de Negócios → associados com uma função específica do negócio;
• Serviço de Coordenação ou de Processo → apoiam processos de negócio mais gerais que envolvem diferentes atores e atividades.
Projeto de Interface do Serviço → interface lógica (operações) + estrutura das mensagens enviadas e recebidas + WSDL.
Implementação e implantação do serviço → codificação e disponibilização do serviço no Servidor Web (para tornar o serviço público deve ser feita uma descrição UDDI).
Informações básicas da UDDI:
• Detalhes dos negócios que fornecem o serviço → confiabilidade (usuário pode verificar as credenciais do provedor);
• Descrição informal das funcionalidades do serviço;
• Informações sobre a localização da especificação WSDL associada ao serviço; • Informações de assinatura → para obter atualizações de serviços.
UNIDADE 20: Desenvolvimento de Software Orientado a Aspectos
AOSD (Aspect Oriented Software Development) → abordagem com a intenção de resolver problemas de reuso de componentes, criando um novo tipo de abstração (o aspecto).
Essa abordagem permite a separação de assuntos em elementos diferentes ao invés de manter tudo na mesma abstração lógica.
É uma forma de tornar alguns elementos mais 'especializados' e melhorar a granularidade do programa. Mas, pra fazer sentido, o assunto tem que ser algo de interesse dos stakeholders (ou seja,
tem que ter vínculo com o mundo real).
Os assuntos de stakeholders podem ser agrupados: • Funcionais → funcionalidade específica;
• Qualidade de Serviço → relacionados ao ambiente funcional do sistema ( desempenho, confiabilidade e disponibilidade);
• Política → são as políticas gerais que governam o uso do sistema (proteção, segurança e assuntos relacionados às regras de negócio);
• Sistema → relacionados aos atributos do sistema como um todo ao invés de requisitos individuais, facilidade de manutenção e configuração;
• Organizacionais → dizem respeito à organização (produção de sistema dentro do orçamento, uso de ativos ou manutenção da reputação da empresa);
UNIDADE 21: Engenharia de Software com Aspectos
Adotar uma abordagem orientada a aspectos → conceito de separação em assuntos como base para analisar requisitos.
Identificar e modelar assuntos → parte do processo de requisitos e projeto.
Exemplo em UML (p.94) → um sistema central que atende aos requisitos gerais, com extensões que atender a assuntos adicionais dos stakeholders, que devem ser integrados ao sistema central.
Tipos de extensões derivadas (em função dos assuntos):
• Extensões Funcionais Secundárias → adicionam capacidades funcionais para funcionalidades fornecidas no Sistema Central;
• Extensões de Políticas → adicionam capacidades funcionais para apoiar políticas organizacionais (p.ex. Características de proteção);
• Extensões de QoS (Quality of Service) → adicionam capacidades funcionais para atender requisitos de qualidade de serviço especificadas para o sistema;
• Extensões de Infraestrutura → adicionam capacidades funcionais para dar suporte a implementação de alguma plataforma específica.
*aspectos são um meio para implementar extensões. UNIDADE 22: Estimativa de Custo de Software
Exige experiência, dados históricos (métricas) e previsões quantitativas. Estimativas possuem riscos inerentes (incertezas).
Apesar do risco e incerteza, é um processo importante para o projeto e deve ser feito, apoiado em algumas técnicas e ferramentas já existentes.
Históricos de atividades anteriores são muito úteis para dar maior segurança às estimativas. Variabilidade nos requisitos → instabilidade no custo e no cronograma.
Escopo mal entendido ou requisitos sujeitos à mudanças → incerteza e riscos aumentam. Tarefas para o planejamento de projeto quanto às estimativas de custo:
• Estabelecer o escopo; • Determinar a viabilidade; • Analisar riscos;
• Definir recursos necessários (humanos, software e ambiente); • Estimar custo e esforço;
UNIDADE 23: Métricas para pequenas organizações
Medição → ferramenta de gestão e apoio ao gerente de projetos. Pode ser aplicada para: • caracterizar esforço como referência para futuros projetos;
• determinar o status do projeto em relação ao planejamento; • previsões (de processos, relacionamentos
Possuir métricas é essencial para qualquer organização, porém deve ser simples, ajustada as necessidades locais e tem que possuir valor.
A seguir cita um exemplo (p.102-103).
Orientações do SEI (Software Engineering Institute) para um programa de métricas: • identificar as metas do negócio;
• identificar o que precisa conhecer ou aprender; • identificar submetas;
• identificar entradas e atributos relacionados as submetas; • formalizar as metas de medição;
• identificar perguntas e indicadores desejados; • identificar elementos de dados requeridos;
• definir as medidas a serem feitas e operacionalizá-las;
• identificar as ações a serem tomadas para implementar as medidas; • montar um plano para implementar as medições.
UNIDADE 24: Estimativa de Projeto de Software (Custo e Esforço) Boas práticas:
• adiar estimativas até que o projeto esteja mais adiantado; • basear-se em projetos semelhantes;
• usar técnicas de decomposição simples para gerar estimativas de custo e esforço; • usar modelos empíricos para estimativas.
Tamanho do software pode ser estimado usando técnicas como “Linhas de Código” (LOC) ou “Pontos de Função” (FP). A técnica FP pode ser usada a partir dos requisitos (e é melhor do que a LOC).
Estimativas a partir de Casos de Uso não é simples porque: • Casos de uso não possuem estilo formal;
• representam a visão de usuário (externa) do sistema, descrita em diferentes níveis de abstração;
• não tratam da complexidade das funções descritas e nem descrevem comportamentos complexos.
Podem ser usados modelos empíricos e estimativas a partir de regressão de dados coletados em sistemas anteriores.
UNIDADE 25: Modelos de Estimativa de Software - Cocomo II
COCOMO (Constructive Cost Model) → hierarquia de modelos de estimativa de software, que busca medir esforço, prazo, tamanho de equipe e custo necessário para desenvolvimento. Ele fornece suporte para as etapas de planejamento, preparação do projeto, negociação de contratos, avaliação de propostas e recursos (tecnológicos e humanos).
É necessário ter uma estimativa de tamanho do software. Modelos que o COCOMO contempla:
• Composição da Aplicação → nos primeiros estágios da Engenharia de Software
(prototipagem de interfaces com usuário, avaliação de desempenho e análise da maturidade tecnológica);
• Primeiro Estágio do Projeto → após a estabilização dos requisitos e a definição da arquitetura básica do software;
• Pós-arquitetura → durante a construção do software
Opções de dimensionamento de software que podem ser utilizadas pelo COCOMO: • Pontos por objeto;
• Pontos por função; • Linhas de código fonte.
O COCOMO II estima custo e tempo em pessoas/mês e meses, para determinação de um baseline (já com 20% de adicional como margem de erro).
UNIDADE 26: Engenharia de Software para Web Características de aplicações Web:
• Concentração em Redes → internet, intranet ou extranet; • Concorrência → muitos usuários (acessos);
• Carga imprevisível → escalabilidade; • Tempo de resposta → é um fator relevante; • Disponibilidade → serviço deve estar online;
• Orientada a dados → foco em Banco de Dados (geralmente); • Sensível ao Conteúdo;
• Evolução contínua;
• Imediatismo → aplicações devem ser disponibilizadas aos usuários muito rapidamente; • Segurança;
• Estética/Aparência;
UNIDADE 27: Engenharia de Software para Web (WebE) – Metodologia Modelo de processo tem 3 características principais:
• Entrega incremental; • Modificações contínuas; • Cronogramas curtos.
O que deve ser considerado no projeto WebE?
• A importância da página principal do site (se contém informação útil ou apenas uma lista de links);
• Layout de página efetivo;
• Opções de mídia com maior impacto (gráficos, texto, vídeo, áudio) e quando aplicar cada um;
• Qual o trabalho que o usuário está disposto a fazer (quantos cliques);
• A complexidade de formulários de entrada sem que se tornem desagradáveis aos usuários; • Importância dos recursos de busca;
UNIDADE 28: Engenharia de Software para Web - Oohdm
Object Oriented Hypermedia Design Method → metodologia para desenvolvimento
de aplicações Web, cujas particularidades (navegação, interface e implementação) e complexidade crescente, apresentam requisitos próprios que as técnicas tradicionais de Engenharia de Software não são adequadas a resolver.
Possui 4 atividades diferentes:
• Modelo conceitual → semântica do domínio da aplicação;
• Projeto de Navegação → leva em conta perfil de usuário e tarefas a serem executadas (ênfase em aspectos cognitivos);
• Projeto da Interface Abstrata → modela objetos perceptíveis, implementa metáforas escolhidas e descreve interface para objetos navegacionais;
• Implementação → projeto deve ser mapeado para artefatos de implementação.
*p.124 tem uma tabela entre as 4 atividades e as saídas a serem produzidas em cada uma delas. A vantagem é introduzir à WebE um formalismo análogo as técnicas tradicionais de Engenharia de Software, que permitem controle do projeto, robustez, reuso e outros.
UNIDADE 29: Planejamento de projetos baseados em Web
Projetos de tamanho pequeno ou médio (menos de 5 meses) → abordagem ágil: • entender o escopo, dimensões das modificações e restrições do projeto; • definir estratégia de plano incremental;
• realizar análise de risco (risco de cronograma e tecnologia); • desenvolver rápida estimativa (tópicos macro);
• descrever o processo (um conjunto de tarefas significativas);
• estabelecer um cronograma para tarefas de curto prazo com granularidade fina e para tarefas dos incrementos com granularidade grossa;
• definir mecanismos de acompanhamento do projeto (entregas, quantos casos de uso foram implementados e quantos faltam, etc);
• estabelecer abordagem de modificação (definir em qual iteração é melhor introduzir a modificação).
UNIDADE 30: Ferramentas de Software para Gestão de Projetos Web
Objetivos das ferramentas → estabelecer tarefas, atribuir esforço e responsabilidade para cada uma, criar as dependências entre tarefas, definir o cronograma e acompanhamento e controle do projeto. Exemplo: Business Engine, iTeamWork (livre), OutProject, Proj-Net, StarWright.
