Engenharia de Software Pressman 7ed

Prévia do material em texto

Engenharia de Software
	A engenharia de software abrange um processo, um conjunto de métodos (práticas) e um leque de ferramentas que possibilitam aos profissionais desenvolverem software de altíssima qualidade.
	A engenharia de software é uma tecnologia em camadas:
Foco na qualidade: é a pedra fundamental que sustenta a engenharia de software
Processo: é a liga que mantém as camadas de tecnologia coesas e possibilita o L de software de forma racional e dentro do prazo. O processo define uma metodologia que deve ser estabelecida para a entrega efetiva de tecnologia de engenharia de software. O processo de software constitui a base para o controle de gerenciamento de projetos de software e estabelece o contexto no qual são aplicados métodos técnicos, são produzidos produtos derivados (modelos, documentos, dados, relatórios, formulários, etc), são estabelecidos marcos, a qualidade é garantida e mudanças são geridas de forma apropriada.
Métodos: fornecem as informações técnicas para desenvolver software. Os métodos envolvem uma ampla gama de tarefas, que incluem: comunicação, análise de requisitos, modelagem de projeto, construção de programa, testes e suporte. Os métodos de engenharia de software baseiam-se em um conjunto de princípios básicos que governam cada área de tecnologia e inclui tarefas de modelagem e outras técnicas descritivas.
Ferramentas: fornecem suporte automatizado ou semiautomatizado para o processo e para os métodos. Quando as ferramentas são integradas, de modo que as informações criadas por uma ferramenta possam ser usadas por outra, é estabelecido um sistema para o suporte ao desenvolvimento de software, denominado engenharia com auxílio do computador.
As cinco atividades genéricas de metodologia de processo:
Comunicação: antes de iniciar qualquer trabalho técnico, é de vital importância comunicar-se e colaborar com o cliente (e outros interessados).
Se o processo fosse consideravelmente mais complexo, com muitos interessados; a atividade de comunicação poderia ter seis ações distintas: inserção, elucidação, elaboração, negociação, especificação e validação. (IEENEV)
Planejamento: qualquer jornada complicada pode ser simplificada caso exista um mapa. Descrevendo as tarefas técnicas a seremconduzidos, os riscos prováveis, os recursos que serão necessários, os produtos resultantes a ser produzidos e um cronograma de trabalho.
Modelagem: criar modelos para melhor entender as necessidades do software e o projeto que irá atender a essas necessidades.
Construção: combina geração de código e testes necessários para revelar erros na codificação.
Emprego/Entrega: é quando o software é entregue ao cliente, que avalia o produto e fornece feedback.
Modelo de Processo
	Padrão de processo descreve um problema de processo encontrado durante o trabalho de engenharia de software, identificando o ambiente onde foi encontrado e sugerindo uma ou mais soluções comprovadas para o problema.
Modelo de processo prescritivo
Modelo Cascata/Ciclo de vida Clássico
	Sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, começando com o levantamento de necessidades por parte do cliente, avançando pelas fases de planejamento, modelagem, construção, emprego e culminando no suportecontínuo do software concluído.
Modelo Incremental
	Se o cliente precisa da entrega até uma determinada data impossível de ser atendida, sugira a entrega de um ou mais incrementos até a data e o restante do software (incrementos adicionais) posteriormente.
	Pode ser necessário o rápido fornecimento de um determinado conjunto funcional aos usuários, para somente após esse fornecimento, refinar e expandir sua funcionalidade em versões de softwares posteriores.
	Combina elementos dos fluxos de processos lineares e paralelos; aplica sequências lineares, de forma escalonada, à medida que o tempo vai avançando.
Modelos de processo evolucionário
	São iterativos. Apresentam características que possibilitam desenvolver versões cada vez mais completas do software.
Modelo Prototipação
	Quando o cliente tiver uma necessidade legítima, mas sem a mínima ideia em relação a detalhes, faça um protótipo para uma primeira etapa.
	O paradigma da prototipação começa com a comunicação. Uma iteração da prototipação é planejada rapidamente e ocorre a modelagem(na forma de um “Projeto rápido”, por exemplo, o layout da interface com o usuário ou os formatos de exibição na tela). O projeto rápido leva à construção de um protótipo que fornecerá um retorno (feedback), que servirá para aprimorar os requisitos.
	Na sua forma ideal, o protótipo atua como um mecanismo para identificar os requisitos do software.
Modelo Espiral
	O modelo espiral pode ser adaptado para ser aplicado ao longo de todo o ciclo de vida de uma aplicação, desde o desenvolvimento de conceitos até sua manutenção.
	O modelo espiral é um modelo de processo de software evolucionário que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo cascata.
	O modelo espiral é uma abordagem realista para o desenvolvimento de sistemas e de software em larga escala. Esse modelo usa a prototipação como mecanismo de redução de riscos e, mais importante, torna possível a aplicação da prototipação em qualquer estágio do processo evolutivo do produto.
	Requer consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado apropriadamente, reduz os riscos antes de se tornarem problemáticos.
	Pontos âncora de controle – uma combinação de produtos de trabalho e condições que são satisfeitas ao longo do trajeto da espiral – são indicados para cada passagem evolucionária.
Desenvolvimento baseado em componentes
	Incorpora muitas das características do modelo espiral. Desenvolve aplicações a partir de componentes de software pré-empacotados.
	Desenvolvimento Baseado em Componentes aparece como uma técnica que consiste no desenvolvimento de aplicações a partir de componentes interoperáveis, reduzindo, assim, a complexidade e o custo do desenvolvimento, e melhorando a qualidade do produto de software.
	Conduz ao reuso do software e a reusabilidade proporciona uma série de benefícios mensuráveis aos engenheiros de software.
Modelo de métodos formais
	Engloba um conjunto de atividades que conduzem à especificação matemática formal do software. Os métodos formais possibilitam especificar, desenvolver e verificar um sistema baseado em computador através da aplicação de uma notação matemática rigorosa.
Processo Unificado (UP/RUP)
	É o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. O UP de desenvolvimento de sistemas combina os ciclos iterativo e incremental para a construção de softwares.
É uma tentativa de aproveitar os melhores recursos e características dos modelos tradicionais de processo de software, mas caracterizando-os de modo a implementar muitos dos melhores princípios do desenvolvimento ágil de software.
	Ajuda o arquiteto a manter o foco nas metas corretas, tais como compreensibilidade, confiança em mudanças futuras e reutilização. Sugere um fluxo de processo iterativo e incremental.
Fase de concepção: envolve tanto a atividade de comunicação com o cliente como a de planejamento. Colaborando com os interessados, identificam-se as necessidades de negócio para o software; propõe-se uma arquitetura rudimentar para o sistema e se desenvolve um planejamento para a natureza iterativa e incremental do projeto decorrente.
Fase de Elaboração:fase na qual o produto é detalhado o suficiente para permitir um planejamento acurado da fase de construção. Refina e expande os casos práticos preliminares, desenvolvidos como parte da fase de concepção, e amplia a representação da arquitetura, incluindo cinco visões diferentes do software: modelo de caso prático, modelo de requisitos, modelo de projeto, modelo de implementação e modelo de emprego. Em alguns casos, a elaboração gera uma “base dearquitetura executável”, consistindo num sistema executável de “degustação”.
Fase de construção:fase na qual é construída uma versão completamente operacional. É idêntica à atividade de construção definida para o processo de software genérico. Tendo como entrada o modelo de arquitetura, a fase de construção desenvolve ou adquire componentes de software; esses componentes farão com que cada caso prático se torne operacional para os usuários finais. À medida que os componentes estão sendo implementados, desenvolve-se e executam-se testes de unidades para cada um deles. Além disso, realizam-se atividades de integração (montagem de componentes e testes de integração).
Fase de transição: entrega-se o software aos usuários finais para testes beta e o feedback dos usuários relata defeitos e mudanças necessárias.
Fase de produção: coincide com a atividade de emprego do processo genérico. Durante essa fase, monitora-se o uso contínuo do software, disponibiliza-se suporta para o ambiente operacional, realiza-se e avalia-se relatórios de defeitos e solicitações de mudanças.
Modelo de processo Pessoal e de Equipe
	Num cenário ideal, uma pessoa poderia desenvolver processos que se adequasse melhor às suas necessidades e, simultaneamente, atendesse às necessidades mais amplas da equipe e da organização. De forma alternativa, a própria equipe pode criar seu próprio processo e, ao mesmo tempo, atender às necessidades mais específicas dos indivíduos e às necessidades mais amplas da organização.
Processo de software Pessoal (PSP)
É um framework para auxiliar o desenvolvedor a estimar e planejar suas tarefas, acompanhar sua performance em relação ao planejado e melhorar a qualidade dos produtos produzidos
Enfatiza a medição pessoal, tanto do artefato de software gerado quanto da qualidade resultante dele. Além disso, responsabiliza o profissional pelo planejamento de projetos e lhe dá poder para controlar a qualidade de todos os artefatos de software desenvolvidos.
O PSP enfatiza a necessidade de registrar e analisar tipos de erros cometidos, para que se possa elaborar estratégias para eliminá-los.
	O modelo PSP define 5 atividades estruturais:
Planejamento: essa atividade isola os requisitos e desenvolve as estimativas de porte e de recursos. Além disso, faz-se uma estimativa dos defeitos.
Projeto de alto nível:desenvolvem-se especificações externas para cada componente a ser construído e elabora-se um projeto de componentes. Quando há incerteza, constroem-se protótipos. Todos os problemas são registrados e localizados.
Revisão de projeto de alto nível:aplicam-se métodos de verificação formais para revelar erros no projeto.
Desenvolvimento:o projeto em nível de componentes é refinado e revisado. Código é gerado, revisado, compilado e testado.
Autópsia:usando as medidas e métricas coletadas, é determinada a eficácia do processo.
Processo de software em Equipe (TSP)
	O objetivo do TSP é criar um equipe de projetos “autodirigida”, que se organize por si mesma para produzir software de alta qualidade.
	O TSP define as seguintes atividades metodológicas: lançamento do projeto, projeto de alto nível, implementação, integração e testes e autópsia. Essas atividades capacitam a equipe a planejar, projetar e construir software de maneira disciplinada, ao mesmo tempo em que mede quantitativamente o processo e o produto.
Desenvolvimento Ágil
Princípio de desenvolvimento que foca talentos e habilidade de indivíduos, moldando o processo de acordo com as pessoas e as equipes específicas.
	Métodos ágeis se desenvolveram em esforço para sanar fraquezas reais e perceptíveis da engenharia de software convencional.
	Umas das características ágil é sua habilidade de reduzir os custos da mudança ao longo de todo o processo.
	Porem, agilidade consiste em algo mais que uma resposta à mudança. Ela incentiva a estruturação e as atitudes em equipe que tornam a comunicação mais fácil (entre engenheiros da equipe, entre o pessoal ligado à tecnologia e o pessoal da área comercial, entre os engenheiros de software e seus gerentes). Enfatiza a entrega rápida do software operacional e diminui a importância dos artefatos intermediários; assume o cliente como parte da equipe de desenvolvimento e trabalha para eliminar a atitude de “nós e eles”; reconhece que o planejamento em um mundo incerto tem seus limites e que o plano de projeto deve ser flexível.A agilidade pode ser aplicada a qualquer processo de software.
	Um processo ágil reduz o custo das alterações porque o software é entregue de forma incremental e as alterações podem ser mais bem controladas dentro de incrementais.
	Processo ágil deve ser adaptável. Um processo ágil de software deve adaptar incrementalmente. Para conseguir uma adaptação incremental, a equipe ágil precisa de feedback do cliente. Um efetivo catalisador para feedback de cliente é um protótipo operacional ou parte de um sistema operacional.
	“O desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o processo de acordo com as pessoas e as equipes específicas”.
As características das que devem estar presente nas pessoas integrantes de uma equipe de software eficiente:
Competência
Foco comum
Colaboração
Habilidade na tomada de decisão
Habilidade de solução de problemas confusos
Confiança mútua e respeito
Auto-organização
Modelos de Processos Agéis
Extreme Programming – XP (Programação Extrema)
	É uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.
	Os 5 valores fundamentais para todo o trabalho como parte da XP: Comunicação, Simplicidade, Feedback, Coragem e Respeito.
	O XP faz uso do teste de unidades como sua tática de testes primária.
Emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de 4 atividades metodológicas:
Planejamento:se inicia com a atividade de “ouvir” – uma atividade de levantamento de requisitos. A atividade de “ouvir” conduz à criação de um conjunto de “histórias” que descreve o resultado, as características e a funcionalidade requisitados para o software a ser construído. Se a “história”requerer, por estimativa, mais do que três semanas de desenvolvimento, é solicitado ao cliente para dividir a história em histórias menores e a atribuição de valor e custo ocorre novamente.
Projeto:é preferível sempre um projeto simples do que uma representação mais complexa. A XP encoraja o uso de cartões CRC (Classe – Responsabilidade – Colaborador) que identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Se um difícil problema de projeto for encontrado como parte do projeto de uma história, a XP recomenda a criação imediata de um protótipo operacional dessa parte do projeto, denominada solução pontual.
Codificação: a equipe não passa para a codificação, mas sim, desenvolve uma série de testes de unidades que exercitarão cada uma das histórias a ser inclusas na versão corrente. Estando o código completo, pode ser testado em unidade imediatamente, e, dessa forma, prover, instantaneamente, feedback para os desenvolvedores. Um conceito-chave na atividade de codificação é a programação em dupla. Usa Refabricação que aprimora a estrutura interna de um projeto (ou código-fonte) sem alterar sua funcionalidade ou comportamento externos.
Testes:Teste de integração, teste de validação, teste de regressão e teste de aceitação (teste de cliente).
Desenvolvimento de Software Adaptativo (ASD)
	É uma técnica para construção de software e sistemas complexos. Concentram-se na elaboração humana e na auto-organização.
	A ênfase global da ASD está na dinâmica das equipes auto organizadas, na colaboração interpessoal e na aprendizagem individual e da equipe que levam as equipes de projeto de software a uma probabilidade muito maior de sucesso.
	Ele define um “ciclo de vida” ASD que incorpora 3 fases: Especulação,Colaboração e Aprendizado.
	Durante a especulação, o projeto é iniciado e conduzido o planejamento de ciclos adaptáveis, que usa as informações do início do projeto para definir o conjunto de ciclos de versão que serão requisitados para o projeto.
	A colaboração não é algo fácil, envolve comunicação e trabalho em equipe, mas também enfatiza o individualismo, pois a criatividade individual desempenha um importante papel no pensamento colaborativo. Trata-se, sobretudo, de uma questão de confiança.
	No aprendizado as equipes ASD aprendem de três maneiras: grupos focados, revisões técnicas e autópsia de projetos. É um elemento chave para conseguir uma equipe “auto-organizada”.
SCRUM
	É um processo de desenvolvimento iterativo e incremental.
O princípio do Scrum é consistente com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo chamado Sprint.
	Engloba um conjunto de padrões de processos enfatizando prioridades de projeto, unidades de trabalho compartimentalizadas, comunicação e feedback frequente por parte dos clientes.
	O Scrum enfatiza o uso de um conjunto de padrões de processo de software que provaram serem eficazes para projetos com prazos de entrega apertados, requisitos mutáveis e críticos de negócio. Esses padrões são:
Registro pendente de trabalhos (Backlog):uma lista com prioridades dos requisitos ou funcionalidades do projeto que fornecem valor comercial ao cliente.
Urgências sprints:consistem de unidades de trabalho solicitadas para atingir um requisito estabelecido no registro de trabalho (Backlog) e que precisa ser ajustado dentro de um prazo já fechado (janela de tempo).
Alterações: não são introduzidas durante execução de urgências (sprint).
Reuniões Scrum: são reuniões curtas (tipicamente 15 min), realizadas diariamente pela equipe Scrum.
Demos: entrega do incremento de software ao cliente para que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente.
Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)
	É uma abordagem de desenvolvimento ágil que “oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado através do uso da prototipagem incremental em um ambiente de projeto controlado”. Pode adotar a tática de uma outra abordagem ágil como a XP.
	É um processo de software interativo. Ou seja, somente o trabalho suficiente é requisitado para cada incremento, para facilitar o movimento para o próximo incremento.
	O cliclo de vida DSDM define 3 ciclos iterativos diferentes, precedidos por 2 atividades de ciclo de vida adicionais:
Estudo da viabilidade: avalia se a aplicação é ou não um candidato viável para o processo de DSDM.
Estudo do negócio: estabelece os requisitos funcionais e de informação que permitirão à aplicação agregar valor de negócio; define também a arquitetura básica da aplicação e identifica os requisitos de facilidade de manutenção para a aplicação.
Iteração de modelos funcionais:produz um conjunto de protótipos incrementais que demonstram funcionalidade para o cliente.
Iteração de projeto e desenvolvimento:revisita protótipos desenvolvidos durante a iteração de modelos funcionais para assegurar-se de que cada um tenha passado por um processo de engenharia para capacitá-los a oferecer, aos usuários finais, valor de negócio em termos operacionais.
Implemetação: aloca a última versão do incremento de software no ambiente operacional.
Crystal
	A família Crystal de métodos ágeis visa conseguir elaborar uma abordagem de desenvolvimento de software que priorizasse a adaptabilidade.
	A família Crystal é, na verdade, um conjunto de exemplos de processos ágeis que provaram ser efetivos para diferentes tipos de projetos.
Desenvolvimento Dirigido a Funcionalidade (FDD)
	É um modelo de processos prático para a engenharia de software orientada a objetos. O FDD adota 3 filosofias que: (1) enfatiza a colaboração entre pessoas da equipe FDD; (2) gerencia problemas e complexidade de projetos utilizando a decomposição baseada em funcionalidades, seguida pela integração dos incrementos de software; e (3) comunicação de detalhes técnicos usando meios verbais, gráficos e de texto.
	O FDD enfatiza as atividades de garantia da qualidade de software por meio do encorajamento de uma estratégia de desenvolvimento incremental, o uso inspeções do código e do projeto, a aplicação de auditorias para garantia da qualidade de software, a coleta de métricas e o uso de padrões.
	No contexto do FDD, funcionalidade “é uma função valorizada pelo cliente passível de ser implementada em duas semanas ou menos”.
	A abordagem FDD define 5 atividades metodológicas “Colaborativas”(no FDD estas são denominadas “Processos”).
Desenvolver um Modelo Geral
Construir uma Lista de Funcionalidades
Planejar por Funcionalidades
Projetar por Funcionalidades
Desenvolver por Funcionalidades
O FDD define seis marcos durante o projeto e a implementação de uma funcionalidade: “desenrolar do projeto, projeto, inspeção de projeto, codificação, inspeção de código, progressão para construção/desenvolvimento”.
Desenvolvimento de Software Enxuto (LSD)
	Os princípios enxutos que inspiraram o processo LSD podem ser sintetizados em: eliminar desperdício, incorporar qualidade, criar conhecimento, adiar compromisso, entregar rápido, respeitar as pessoas e otimizar o todo.
	Eliminar desperdíciono contexto de um projeto de software ágil pode ser interpretado como:
Não adicionar recursos ou funções estranhas
Avaliar o impacto do custo e do cronograma de qualquer requisito solicitado recentemente
Eliminar quaisquer etapas de processo supérfluas
Estabelecer mecanismos para aprimorar o modo pelo qual a equipe levanta informações
Assegurar-se de que os testes encontrem o maior numero de erros possíveis
Reduzir o tempo necessário para solicitar e obter uma decisão que afete o software ou o processo aplicado para cria-lo
Racionalizar a maneira pela qual informações são transmitidas a todos envolvidos no processo
Modelo Ágil (AM)
	Consiste em uma metodologia baseada na prática, voltada para o modelamento e documentação de sistemas com base em software. Simplificando, modelagem ágil consiste em um conjunto de valores, princípios e práticas voltados para a modelagem do software que pode ser aplicados em um projeto de desenvolvimento de software de forma leve e efetiva. Os modelos ágeis são mais efetivos do que os tradicionais pelo fato de serem meramente bons, pois não têm obrigação de ser perfeitos.
	Sua filosofia reconhece que uma equipe ágil deve ter a coragem de tomar decisões que possam causar a rejeição de um projeto e sua refabricação. A equipe também deve ter humildade para reconhecer que os profissionais de tecnologia não possuem toda as respostas e que os experts em negócios e outros envolvidos devem ser respeitados e integrados ao processo.
	O que torna a AM única são:
Modelo com um objetivo: o desenvolvedor que utilizar AM deve ter um objetivo antes de criar o modelo (por exemplo, comunicar informações ao cliente ou ajudar a compreender melhor algum aspecto do software).
Use modelos múltiplos: há muitos modelos e notações diferentes que podem ser usados para descrever software.
Viajar leve: é uma filosofia apropriada para todo o trabalho de engenharia de software. Construa apenas aqueles modelos que forneçam valor...Nem mais, nem menos.
Conteúdo é mais importante do que a representação
Tenha conhecimento, domínio dos modelos e das ferramentas que for utilizar
Adapte localmente
Processo Unificado Ágil (AUP)
	Adota uma filosofia “serial para o que é amplo” e “iterativo para o que é particular” no desenvolvimento de sistemas computadorizados. Adotando as atividades em fases UP clássicas – início, elaboração, construção e transição –, AUP fornece uma camada serial(isto é, uma sequência linear de atividades de engenharia de software) que capacita uma equipe a visualizar o fluxo do processo geral de um projeto de software.
	Cada iteração AUP dirige-se para as seguintes atividades:
Modelagem: representações UML do universo do negócio e do problema são criadas
Implementação: os modelos são traduzidos para o código-fonte
Teste: executa uma série de testes para descobrir erros e assegurar que o código-fonte se ajuste aos requisitos
Aplicação: enfoca entrega de um incremento de software e a aquisição de feedback dos usuários finais
Configuração e gerenciamento de projeto: refere-se a gerenciamento de alterações, de riscos e de controle de qualquer artefato persistente que sejam produzidos por uma equipe.
Gerenciamento do ambiente: coordena a infraestrutura de processos que inclui padrões, ferramentas e outras tecnologias de suporte disponíveis para a equipe.
Engenharia de Requisitos
	É uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e continua na de modelagem. Ela deve ser adaptada às necessidades do processo, do projeto, do produto e das pessoas que estão realizando o trabalho.
	A engenharia de requisitos fornece o mecanismo apropriado para entender aquilo que o cliente deseja, analisando as necessidades, avaliando a viabilidade, negociando uma solução razoável, ESPECIFICANDO A SOLUÇÃO SEM AMBIGUIDADES.
Requisitos Funcionais – descrevem o que o sistema deve fazer e o que não deve fazer.
Requisitos Não Funcionais – ligadas as restrições sobre os serviços ou funções oferecidas pelo sistema. Os requisitos não funcionais mapeiam os aspectos qualitativos de um software, por exemplo: performance (tempo de resposta); segurança (restrições de acesso, privilégios); perspectiva do usuário (padrão das cores, disposição dos objetivos na tela); comunicabilidade (e-mail, VoIP, Browser); usabilidade e portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis, desktop, note).  Como qualquer outro tipo de requisito, ele deve ser levantado, analisado, especificado e validado
Requisitos Organizacionais: são consequências das políticas e procedimentos organizacionais, como padrões, processos, etc.
Externo: são externos ao sistema e seu desenvolvimento.
Produto: especificam que o software entregue deve se comportar de um determinado produto.
Requisitos de Domínio – requisitos que vem do domínio da aplicação do sistema	 e refletem características ou restrições para aquele domínio. Podem ser requisitos FUNCIONAIS e NÃO FUNCIONAIS.
Requisitos Permanentes – relativamente estáveis, pois são derivados da atividade principal.
Requisitos Voláteis – provavelmente irão mudar durante o processo de desenvolvimento do sistema ou depois que o sistema estiver em operação.
Requisitos Mutáveis: mudam devido a mudanças no ambiente no qual a organização está operando.
Requisitos Emergentes – surgem à medida que a compreensão do cliente se desenvolve.
Requisitos Consequentes – estão diretamente ligados à introdução de sistemas de computação na empresa, que podem modificar processos e criar novos métodos de trabalho.
Requisitos de Compatibilidade – dependem de outro equipamento ou processo.
Requisitos de Usuário – descrevem os requisitos FUNCIONAIS e NÃO FUNCIONAIS de um sistema de maneira que sejam compreensíveis pelos usuários do sistema que não possuam nenhum conhecimento técnico detalhado. Declarações em linguagem natural e em diagramas.
Requisitos de Sistema – especificação completa e detalhada de todo o sistema. Descrevem os requisitos FUNCIONAIS e NÃO FUNCIONAIS.
Problemas de Levantamento de Requisitos
Problemas de escopo: requisitos técnicos desnecessários confundem o entendimento da solução esperada.
Problema de entendimento: Cliente não tem domínio suficiente do problema. Requisitos ambíguos e difíceis de testar.
Problemas de volatilidade: Requisitos mudam ao longo do tempo.
Concepção: Objetiva entender o problema, quais os envolvidos, a natureza da solução e iniciar o processo de comunicação entre clientes.
Levantamento: Descobrir objetivos do sistema e do produto.
Problemas de escopo: limites não são identificados corretamente.
Problemas de entendimento: cliente não tem domínio suficiente do problema.
Problemas de volatilidade: Requisitos mudam ao longo do tempo.
Elaboração: Refinamento das informações obtidas. Tornar mais claro.
Negociação: Negociar as necessidades conflitantes, definir prioridades e custo em conjunto com recursos necessários.
Especificação: Documento formal com contrato entre as partes.
Validação: Garantir que todos os requisitos tenham sido declarados de acordo com os padrões estabelecidos.
Gestão de requisitos: Visa identificar, controlar e rastrear requisitos e modificações nos requisitos ao longo do projeto. OCORRE DURANTE TODO O PROJETO.
SOMMERVILLE
Estudo de viabilidade (CONCEPÇÃO)
Elicitação de requisitos (LEVANTAMENTO e ELABORAÇÃO): aprender sobre o domínio da aplicação, quais serviços o sistema pode oferecer, o desempenho esperado do sistema, etc.
Entrevista: a equipe de engenharia de requisitos formula questões para os stakeholders sobre o sistema que eles usam e o sistema a ser desenvolvido.
Entrevista abertas: Não existe um roteiro predefinido.
Entrevistas fechadas: Stakeholders responde a um conjunto de perguntas pré-definidas.
Cenários: Exemplos da vida real. Começa com um esboço de interação e depois são adicionados detalhes.
Brainstorming: Técnica para geração de ideias. Consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias. A discussão em grupo é conduzida por um mediador.
Prototipação: Envolve a criação de versões iniciais de um sistema futuro, com o objetivo de realizar verificações e experimentos.
Etnografia: Requisitos sociais e organizacionais. Um analista se insere no ambiente de trabalho onde o sistema é usado.
Pontos de vista: abordagem que reconhece várias perspectivas e fornece um framework para descobrir conflitos nos requisitos definidos por diferentes stakeholders.
Workshop de Requisitos: Espécie de reuniões com um período intensivo e produz resultados rápidos.
JAD: Metodologia criada pela IBM para moderação de discussões de BRAINSTORMING acelerando e consolidando o desenvolvimento de aplicações.
Especificação de requisitos (NEGOCIAÇÃO e ESPECIFICAÇÃO): Processo de descrever os requisitos de usuário e de sistema em um DOCUMENTO DE REQUISITOS.
Validação: Processo de verificar se os requisitos definem o sistema que o cliente realmente quer.
Revisões de Requisitos: Requisitos analisados sistematicamente por uma equipe de revisores.
Facilidade de verificação – O revisor tem conhecimento de algum requisito faltante ou de alguma informação faltante na descrição dos requisitos.
Facilidade de compreensão – Os leitores do documento podem compreender o que os requisitos significam?
Redundância – Há alguma informação desnecessariamente repetida?
Rastreabilidade – Os requisitos são identificados de maneira não ambígua. A origem dos requisitos, em relação ao cliente, deve estar claramente identificada.
Adaptabilidade – Os requisitos estão no lugar certo? Da maneira apropriada?
Prototipagem: Modelo executável é apresentado para usuários finais e clientes.
Geração de casos de teste: Os requisitos devem ser testáveis.
Gestão de requisitos: Compreender e controlar as mudanças de requisitos de sistema.
Modelagem de Requisitos/Modelo de Análise
Análise de Requisitos
	Resulta na especificação de características operacionais do software, indica a interface do software com outros elementos do sistema e estabelece restrições que o software deve atender.
	O modelo de análise e a especificação de requisitos fornecem um meio para avaliar a qualidade assim que o software for construído.
Modelo de projeto
Descrição do Sistema
Modelo de análise
	O modelo de requisitos deve alcançar 3 objetivos primários: 
Descrever o que o cliente solicita
Estabelecer umabase para a criação de um projeto de software
Definir um conjunto de requisitos que possa ser validado assim que o software for construído.
O modelo de análise preenche a lacuna entre uma descrição sistêmica que descreve o sistema como um todo ou a funcionalidade de negócio que é atingida aplicando-se software, hardware, dados, pessoal e outros elementos de sistema e um projeto de software que descreve a arquitetura, a interface do usuário e a estrutura em termos de componentes do software. Resumindo, o modelo de análise deve descrever o que o cliente quer, deve estabelecer uma base para o projeto, bem como definir uma meta para validação.
Análise de domínio
	O objetivo da análise de domínio é encontrar ou criar aquelas classes de análise e/ou padrões de análise largamente aplicáveis de modo que possam ser reutilizados.
	O papel da análise de domínio é descobrir e definir padrões de análise, classes de análise e informações relacionadas que possam ser usados por várias pessoas que trabalham em aplicações similares, mas não necessariamente as mesmas.
	A análise de domínio não examina uma aplicação específica, mas sim o domínio em que a aplicação reside. O intuito é identificar elementos comuns para resolução de problemas que sejam aplicáveis a todas as aplicações no domínio.
Modelos de Requisitos
	Os elementos baseados em cenários representam como o usuário interage com o sistema e a sequência específica de atividades que ocorre à medida que o software é utilizado.
Casos de uso
Histórias de usuários
Os elementos baseados em classes modelam os objetos que o sistema irá manipular, as operações que serão aplicadas aos objetos para efetuar a manipulação, os relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas.
Diagramas de classes
Diagramas de colaboração
Os elementos comportamentais representam como eventos externos mudam o estado do sistema ou as classes que nele residem.
Diagramas de estados
Diagramas de sequência
Os elementos orientados a fluxos representam o sistema como uma transformação de informações, indicando como os objetos de dados são transformados à medida que fluem pelas várias funções do sistema.
Diagrama de Fluxo de dados (DFDs)
Modelos de dados
Projeto de Arquitetura
	Projeto é uma atividade que trata da tomada de decisões importantes, frequentemente de natureza estrutural.
Representa a estrutura de dados e os componentes de programa necessários para construir um sistema computacional. Ele considera o estilo de arquitetura que o sistema assumirá, a estrutura e as propriedades dos componentes que constituem o sistema, bem como as inter-relações que ocorrem entre todos os componentes da arquitetura de um sistema.
	Os métodos de projeto de software são obtidos considerando-se cada um dos três domínios do modelo de análise. Os domínios de dados, funcional e comportamental servem de orientação para a criação do projeto de software.
Arquitetura de Software
	Desde que o primeiro programa foi dividido em módulos, os sistemas de software passaram a ter arquiteturas e os programadores passaram a ser responsáveis pelas interações entre os módulos e as propriedades globais do conjunto.
	Consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca doprojeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre projetos.
	Fornece uma visão holística do sistema a ser construído. Ela representa a estrutura e a organização dos componentes de software, suas propriedades e as conexões entre eles.
	A arquitetura não é software operacional, mas sim, uma representação que nos permite
(1)analisar a efetividade do projeto no atendimento dos requisitos declarados, (2) considerar alternativas de arquitetura em um estágio quando realizar mudanças de projeto ainda é relativamente fácil e (3) reduzir os riscos associados à construção do software.
	O projeto de arquitetura de software considera dois níveis da pirâmide de projeto – projeto de dados e projeto da arquitetura. O projeto de dados permite que representemos o componente de dados da arquitetura em sistemas convencionais e as definições de classes, em sistemas orientados a objetos. O projeto da arquitetura concentra-se na representação da estrutura dos componentes de software, suas propriedades e interações.
Estilos de arquitetura
	Um estilo de arquitetura é uma transformação imposta no projeto do sistema inteiro. O objetivo é estabelecer uma estrutura para todos os componentes do sistema. No caso em que uma arquitetura existente deve sofrer um processo de reengenharia, a imposição de um estilo de arquitetura resultará em mudanças fundamentais na estrutura do software, incluindo uma nova atribuição da funcionalidade dos componentes.
Arquiteturas centralizadas em dados
	Um repositório de dados (por exemplo, um arquivo ou banco de dados) reside no centro dessa arquitetura e é em geral acessado por outros componentes que atualizam, acrescentam, eliminam ou de alguma outra maneira modificam dados contidos no repositório.
	Uma variação dessa abordagem transforma o repositório em um “quadro-negro” que envia notificações ao software-cliente quando os dados de seu interesse mudam.
	As arquiteturas centralizadas em dados promovem a integrabilidade. Isto é, componentes existentes podem ser alterados e novos componentes-clientes acrescentados à arquitetura sem se preocupar com outros clientes.
Arquiteturas de fluxo de dados
	Essa arquitetura se aplica quando dados de entrada devem ser transformados por meio de uma série de componentes computacionais ou de manipulação em dados de saída. Tem um conjunto de componentes, denominados filtros, conectados por tubos que transmitem dados de um componente para o seguinte.
Arquiteturas de chamadas e retornos
Arquiteturas de programa principal/subprograma. Decompõe a função em uma hierarquia de controle na qual um programa “principal” invoca uma série de componentes de programa que, por sua vez, podem invoca outros.
Arquiteturas de chamadas a procedimentos remotos.Os componentes de uma arquitetura de programas principal/subprogramas são distribuídos ao longo de vários computadores em uma rede.
Arquitetura orientada a objetos
	Os componentes de um sistema encapsulam dados e as operações que devem ser aplicadas para manipular os dados. A comunicação e a coordenação entre os componentes são realizadas através da passagem de mensagens.
Arquitetura em camadas
	São definidas várias camadas diferentes, cada uma realizando operações que progressivamente se tornam mais próximas do conjunto de instruções de máquina.
Projeto da Arquitetura
	Quando o projeto da arquitetura se inicia, o software a ser desenvolvido deve ser colocado no contexto – o projeto deveria definir as entidades externas (outros sistemas, dispositivos, pessoas) com as quais o software interage e a natureza da interação.
	Arquétipo é uma abstração (similar a uma classe) que representa um elemento do comportamento do sistema. O conjunto de arquétipos fornece uma coleção de abstrações que deve ser modelada arquiteturalmente caso o sistema tenha de ser construído, porém os arquétipos em si não fornecem detalhes de implementação suficientes.
	Arquétipo é uma classe ou padrão que representa uma abstração central crítica para o projeto de uma arquitetura para o sistema-alvo. A arquitetura do sistema-alvo é composta desses arquétipos, que representam elementos estáveis da arquitetura, porém podem ser instanciados de várias maneiras tomando com base o comportamento do sistema.
Representação do sistema no contexto
	No nível de projeto da arquitetura, um arquiteto de software usa um diagrama de contexto arquitetural (ACD) para modelar a maneira pela qual o software interagecom entidades externas a seus limites. A estrutura genérica do diagramado de contexto:
Sistemas superiores: aqueles sistemas que suam o sistema-alvo como parte de algum esquema de processamento de mãos alto nível.
Sistemas subordinados: aqueles sistemas que são utilizados pelo sistema-alvo e fornecem dados ou processamento necessários para completar a funcionalidade do sistema-alvo.
Sistemas de mesmo nível (pares): aqueles sistemas que interagem em uma base par-a-par (ou seja, as informações são produzidas ou consumidas pelos pares e sistema-alvo).
Atores: entidades (pessoas, dispositivos) que interagem com o sistema-alvo através da produção ou consumo de informações necessárias para o processamento.
	O contexto de arquitetura representa como o software interage com entidades externas a seus limites.
Mapeamento de arquitetura
	Uma técnica de mapeamento, chamada projeto estruturado, é muitas vezes caracterizada como um fluxo de dados – método de projeto orientado, pois fornece uma transição conveniente de um diagrama de fluxo de dados para uma arquitetura de software.
	Para realizar o mapeamento, o tipo de fluxo de informações deve se determinado. Um tipo de fluxo de informações é denominado fluxo de transformação e que apresenta uma característica linear. Os dados fluem para dentro do sistema ao longo de uma trajetória de fluxo de entrada na qual são transformados de uma representação do mundo exterior em uma forma internalizada. Assim que tiverem sido internalizados, são processados em um centro de transformação. Por fim, fluem para fora do sistema ao longo de uma trajetória de fluxo de saídaque transforma os dados para a forma domundo exterior. 
Mapeamento de transformação
	É um conjunto de etapas de projeto que permite que um DFD (Diagrama de fluxo de dados) com características de fluxo de transformação seja mapeado em um estilo de arquitetura específico.
Projeto baseado em Padrões
	Esse método codificado para descrição de problemas e suas soluções permite aos profissionais de engenharia de software adquirir conhecimento do projeto para possibilitar que ele seja reutilizado.
	Um padrão de projeto pode ser caracterizado como “uma regra de três partes que expressa uma relação entre um contexto, um problema e uma solução”. Para projeto de software, o contexto permite ao leitor compreender o ambiente em que o problema reside e qual solução poderia ser apropriada nesse ambiente. Um conjunto de requisitos, incluindo limitações e restrições, atua como um sistema de forças que influencia a maneira pela qual o problema pode ser interpretado em seu contexto e como a solução pode ser efetivamente aplicado.
Tipos de padrões
	Os padrões de projeto abrangem um amplo espectro de abstração e aplicação.
Padrões de arquitetura: descrevem problemas de projeto de caráter amplo e diverso resolvidos usando-se uma abordagem estrutural.
Padrões de dados:descrevem problemas orientados a dados recorrentes e as soluções de modelagem de dados que podem ser usadas para resolvê-los.
Padrões de componentes (também conhecidos como Padrões de projeto): tratam de problemas associados ao desenvolvimento de subsistemas e componentes, a maneira através da qual eles se comunicam entre si e seu posicionamento em uma arquitetura maior.
Padrões de projeto de interfaces:descrevem problemas comuns de interface do usuário e suas soluções com um sistema de forças que inclua características especificas de usuários finais.
Padrões para WebApp: tratam de um conjunto de problemas encontrados aos se construir WebApps e em geral incorpora muitas das demais categorias de padrões que acabamos de mencionar.
TIPOS DE PADRÕES PARTICULARMENTE RELEVANTES EM PROJETOS ORIENTADOS A OBJETOS:
PADRÕES CRIACIONAIS: relacionados à criação de objetos.
Abstract Factory: permite a criação de famílias de objetos relacionados ou dependentes por meio de uma única interface e sem que a classe concreta seja especificada.
Builder: permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
Factory Method: cada subclasse terá um tratamento diferenciado.
Prototype: permite a criação de objetos a partir de um modelo original, ou protótipo.
Singleton: garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
PADRÕES ESTRUTURAIS: Tratam das associações entre classes e objetos.
Adapter: “adapta” uma interface de uma classe para uma que um cliente espera.
Bridge: desacoplar uma abstração da sua implementação, de modo que as duas possam variar independentemente. 
Composite: utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Uma estrutura de objetos em forma de árvore onde cada objeto possui a mesma interface.
Decorator: anexar responsabilidades adicionais a um objeto dinamicamente.
Façade: oferece uma interface única para um conjunto de interfaces de um subsistema.
Flyweight: apropriado quando vários objetos devem ser manipulados em memória sendo que muitos deles possuem informações repetidas.
Proxy: fornece um substituto ou representante de outro objeto para controlar o acesso a ele. É uma classe que funciona como uma interface para outra classe. 
PADRÕES COMPORTAMENTAIS: tratam das interações e divisões de responsabilidades entre classes ou objetos.
Chain of responsability: Objetos e comando são manipulados ou passados para outros objetos através de objetos de processamento com lógica.
Command: Objetos de comando encapsulam uma ação e seus parâmetros.
Interpreter: especifica como entender frases em uma determinada linguagem de programação.
Mediator: a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando.
Memento: permite armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário.
Observer: define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes são notificados e atualizados automaticamente. Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto.
State: usado quando o comportamento de um objeto muda, dependendo do seu estado.
Strategy: permite definir novas operações sem alterar as classes dos elementos sobre os quais opera.
Template Method: define o esqueleto de um algoritmo dentro de um método, transferindo alguns de seus passos para as subclasses.
 Iterator: fornece uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor a sua representação subjacente.
 Visitor: quando se quer acrescentar novos recursos a um composto de objetos e o encapsulamento não é importante.
Linguagens e repositórios de padrões
	Uma linguagem de padrões engloba um conjunto de padrões, cada qual descrito através do uso de uma template de padrões e inter-relacionados para mostrar como esses padrões colaboram para solucionar problemas em um domínio de aplicação.
	Em uma linguagem de padrões, os padrões de projeto são organizados para fornecer um “método estruturado para descrição de práticas de projeto adequadas em um domínio”.
	De certa forma, uma linguagem de padrões é análoga a um manual de instruções em hipertexto para resolução de problemas em áreas de aplicação específicas.
	Em vez de uma lista sequencial de padrões, a linguagem de padrões representa um conjunto interconectado em que o usuário pode partir de um problema de projeto abrangente e “ir fundo” para revelar problemas específicos e suas soluções.
Projeto de Software Baseado em Padrões
O Projeto baseado em padrões parece interessante para o problema que devo resolver. Por onde devo começar?
Certifique-se de ter entendido o quadro geral – o contexto em que o software a ser construído reside. O modelo de requisitos deve comunicar isso a você.
Examine o quadro geral,extraia os padrões presentes neste nível de abstração.
Inicie o seu projeto com os padrões do “quadro geral” que estabeleçam um contexto ou esqueleto para trabalho de projeto posterior
“Trabalhe em direção à essência, partindo do contexto” buscando padrões em níveis de abstração mais baixos que contribuam para a solução de projeto.
Repita os passos 1 a 4 até que o projeto completo ganhe corpo
Refina o projeto adaptando cada padrão às especificidades do software que está tentando construir.
É importante notar que os padrões não são entidades independentes. Os padrões de projeto que estão presentes em nível de abstração elevado influenciarão invariavelmente a maneira pela qual outros padrões serão aplicados em níveis de abstração maus baixos.
Tarefas de projeto
	As tarefas necessárias para criar um projeto baseado em padrões são:
Examine o modelo de requisitos e desenvolva uma hierarquia de problemas
Determine se uma linguagem de padrões confiável foi desenvolvida para o domínio do problema
Inicie com um problema abrangente, determine se um ou mais padrões de arquitetura se encontram disponíveis para ele.
Use as colaborações fornecidas para o padrão de arquitetura, examine problemas de subsistemas ou de componentes e procure padrões apropriados para tratar deles.
Repita os passos de 2 a 5 até que todos os problemas mais amplos tenham sido tratados
Se os problemas de projeto para interfaces do usuário tiverem sido isolados (quase sempre esse é o caso), pesquise os vários repositórios de padrões de projeto para interfaces do usuários em busca de padrões apropriados
Independentemente de seu nível de abstração, se uma linguagem de padrões e/ou repositório de padrões ou padrão individual se mostrarem promissores, compare o problema a ser resolvido em relação ao(s) padrão(ões) existente(s) apresentado(s).
Certifique-se de refinar o projeto à medida que é obtido de padrões usando critérios de qualidade de projeto como guia. 
Padrões de Arquitetura
	Uma arquitetura de software pode ter uma série de padrões de arquitetura que tratam de questões como concorrência, persistência e distribuição:
Controle de acesso: há várias situações em que o acesso a dados, recursos e funcionalidade fornecidos por uma aplicação é limitada a usuários finais especificamente definidos.
Concorrência:muitas aplicações têm de tratar múltiplas tarefas em um modo que simule paralelismo (isso ocorre sempre que vários componentes ou tarefas “paralelos” são administrado por um único processador).
Distribuição: o problema da distribuição trata a maneira pela qual os sistemas ou componentes de sistemas se comunicam entre si em um ambiente distribuído.
Persistência:os dados persistem se sobreviverem depois da execução do processo que o criou. Os dados persistentes são armazenados em um banco de dados ou arquivo podem ser lidos ou modificados por outros processos posteriormente.
Padrões de Projeto para WebApps
	Ao considerarmos os problemas de projeto a ser solucionados quando uma WebApp é construída, vale a pena considerar categorias de padrão concentrando-nos em duas dimensões:
O foco no projeto: indica qual aspecto do modelo de projeto é relevante (por exemplo, arquitetura das informações, navegação, interação). Os padrões para WebApps podem ser classificados usando-se os seguintes níveis de foco do projeto.
Padrões de arquitetura de informações: relacionam-se à estrutura geral do espaço de informações e as maneiras pelas quais os usuários irão interagir com as informações
Padrões de navegação: definem estrutura de links de navegação como hierarquias, anéis, tours e assim por diante.
Padrões de interação: contribuem par ao projeto de interface do usuário.
Padrões de apresentação: ajudam na apresentação do conteúdo à medida que é apresentado ao usuário via interface.
Padrões funcionais: definem os fluxos de trabalho, comportamentos, processamento, comunicação e outros elementos algorítmicos contidos em uma WebApp.
Granularidade:identifica o nível de abstração que está sendo considerado (por exemplo, o padrão se aplica a toda a WebApp ou a uma única página Web, a um subsistema ou um componente WebApp individual). Em termos de nível de granularidade, os padrões podem ser descritos nos seguintes níveis:
Padrões de arquitetura: esse nível de abstração irá, tipicamente, se relacionar a padrões que definem a estrutura geral da WebApp, indicam os relacionamentos entre os diferentes componentes ou incrementos e definem as regras para especificar as relações entre os elementos (páginas, pacotes, componentes, subsistemas) da arquitetura
Padrões de projeto:tratam de um elemento específico do projeto como uma agregação de componentes para resolver algum problema de projeto, relações entre os elementos em uma página ou os mecanismos para efetuar a comunicação componente-para-componente.
Padrões de componentes:esse nível de abstração relaciona-se a elementos individuais de pequena escala de uma WebApp. Entre os exemplos, temos elementos de interação individual (por exemplo, botões de rádio) itens de navegação (por exemplo, como formataríamos links?) ou elementos funcionais (por exemplo, algoritmos específicos).
Conceitos de Qualidade
	No sentindo mais geral, a qualidade de software pode ser definida com: uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aquelas que o utilizam.
	OBJETIVA ASSEGURAR QUE O PRODUTO ATENDE ÀS EXIGÊNCIAS.
Dimensões de qualidade de Garvin
	Garvin sugere que a qualidade deve ser considerada adotando-se um ponto de vista multidimensional que começa com uma avaliação da conformidade e termina com uma visão transcendental. Embora as 8 dimensões de qualidade de Garvin não tenham sido desenvolvidas especificamente para software, elas podem ser aplicadas quando se considera qualidade de software:
Qualidade de desempenho
Qualidade de recursos
Confiabilidade
Conformidade
Durabilidade
Facilidade de manutenção
Estética
Percepção
Fatores de qualidade de McCall
	McCall criou uma proposta de categorização dos fatores que afetam a qualidade de software. Esse fatores de qualidade de software, focam 3 importantes aspectos: (1)as características operacionais, (2) a habilidade de suportar mudanças e a (3) adaptabilidade a novos ambientes. Faz as seguintes descrições:
Correção
Confiabilidade
Eficiência
Integridade
Usabilidade
Facilidade de manutenção
Flexibilidade
Testabilidade
Portabilidade
Reusabilidade
Interoperabilidade
Fatores de qualidade ISSO 9126
	O padrão ISSO 9126 foi desenvolvido como uma tentativa de identificar os atributos fundamentais de qualidade para software de computador. O padrão identifica 6 atributos fundamentais da qualidade:
Funcionalidade
Confiabilidade
Usabilidade
Eficiência
Facilidade de manutenção
Portabilidade
Alcançando a qualidade de software
	A qualidade de software não aparece simplesmente do nada. Ele é o resultado de um bom gerenciamento de projeto e uma prática consistente de engenharia de software. O gerenciamento e a prática são aplicados no contexto de quatro grandes atividades que ajudam uma equipe de software a atingir um alto padrão de qualidade de software:
Métodos de engenharia de software: se nossa expectativa é construir software de alta qualidade, temos de entender o problema a ser resolvido. 
Técnicas de gerenciamento de software:as implicações são claras: se (1) um gerente de projeto usar estimativas para verificar que as datas de entrega são plausíveis, (2) as dependências de cronograma forem entendidas e a equipe resistir à tentação de usar atalhos, (3) o planejamento de riscos for conduzido de modo que problemas não gerem caos, a qualidade do software será afetada de forma positiva.
Controle de qualidade: Focada no produto. PMBOK >> EXECUÇÃO
Garantia de qualidade: Focada no processo. PMBOK >> MONITORAMENTO E CONTROLE
Estratégias de Teste de Software
	Teste é um conjunto de atividades que podem ser planejadascom antecedência e executadas sistematicamente.
	As estratégias de testes têm as seguintes características genéricas:
Para executar um teste eficaz, proceder a revisões técnicas eficazes. Fazendo isso, muitos erros serão eliminados antes do começo do teste.
O teste começa no nível de componente e progride em direção à integração do sistema computacional como um todo.
Diferentes técnicas de teste são apropriadas para diferentes abordagens de engenharia de software e em diferentes pontos no tempo.
O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um grupo independente de teste.
O teste e a depuração são atividades diferentes, mas a depuração deve ser associada com alguma estratégia de teste.
Verificação e Validação
	VERIFICAÇÃO está atrelada às especificações, requisitos ou funcionalidades. “Estamos criando o produto corretamente?” Conjunto de tarefas que garantem que o software implementa corretamente uma função específica.
	VALIDAÇÃO tem a ver com saber se o software atende às reais necessidades do cliente, à satisfação do usuário. “Estamos criando o produto certo?” Conjunto de tarefas que asseguram que o software foi criado e pode ser rastreado segundo os requisitos do cliente.
A verificação e validação incluem uma ampla gama de atividades de SQA (garantia de qualidade de software): revisões técnicas, auditorias de qualidade e configuração, monitoramento de desempenho, simulação, estudo de viabilidade, revisão de documentação, revisão de base de dados, análise de algoritmo, teste de desenvolvimento, teste de usabilidade, teste de qualificação, teste de aceitação e teste de instalação.
Teste de Unidade
	O TESTE DE UNIDADE focaliza o esforço de verificação na menor unidade de projeto do software – O COMPONENTE OU MÓDULO DE SOFTWARE.
	(FCC) Para cada componente ou módulo, testar a interface, a estrutura de dados local, os caminhos independentes ao longo da estrutura de controle e as condições-limite para garantir que a informação flui adequadamente para dentro e para fora do módulo, que todos os comandos tenham sido executados e que todos os caminhos de manipulação de erros sejam testados.
Geralmente é feito pelo próprio desenvolvedor;
Caminhos são testados para descobrir erros dentro dos limites de módulos;
Os dados devem entrar e sair corretamente.
	O projeto dos testes de unidade pode ocorrer antes de começar a codificação ou depois que o código-fonte tiver sido gerado.
	Um TESTE DE UNIDADE AUTOMATIZADO tem três partes:
Uma parte de configuração, em que você inicia o sistema com o caso de teste, ou seja, as entradas e saídas esperadas.
 Uma parte de chamada, quando você chama o objeto ou método a ser testado.
Uma parte de afirmação, em que você compara o resultado da chamada com o resultado esperado. Se a afirmação avaliada for verdadeira, o teste foi bem-sucedido; se for falsa, ele falhou.
Teste de Integração
	Pega as unidades e testa de forma conjunta. É uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces.
Teste de Validação (Aceitação)
	Tem a ver com saber se o software atende às reais necessidades do cliente, à satisfação do usuário.
Começa quando termina o TESTE DE INTEGRAÇÃO, quando os componentes individuais já foram exercitados, o software está completamente montado como um pacote e os erros de interface já foram descobertos e corrigidos.
Tem sucesso quando o software funciona de uma maneira que pode ser razoavelmente esperada pelo cliente.
Objetiva demonstrar conformidade com os requisitos do cliente.
Teste Alfa: Conduzido nas instalações do desenvolvedor pelos usuários finais. Ambiente controlado.
Teste Beta: Conduzido nas instalações de um ou mais usuários finais. Ambiente “CAÓTICO”.
Teste de Sistema
	Testa o sistema como um todo. Testa o software em ambiente operacional, considerando outros elementos externos (Hardware, Pessoas, Informações, etc).
	TIPOS DE TESTE DE SISTEMA SÃO:
Teste de Recuperação: Garantir que o sistema retorne após uma falha. Força o software falhar de várias formas e verifica se a recuperação é executada corretamente.
Teste de Segurança: Verifica possíveis vulnerabilidades do sistema.
Teste de Esforço (ou estresse): Fazer o sistema falhar. Serve para colocar o sistema em situações anormais.
Teste de Desempenho: Objetiva testar em tempo de execução do software. O que acontece quando são aplicadas carga maiores do que a capacidade máxima do servidor.
Teste de Disponibilização (ou Teste de Configuração): Garantir que o software venha a executar em vários ambientes.
Teste de Regressão: Cada vez que um novo módulo é acrescentado como parte do teste de integração, o software muda. É a reexecução do mesmo subconjunto de testes que já foram executados para assegurar que as alterações não tenham propagado efeitos colaterais indesejados.
 
Teste de fumaça: Verifica se a funcionalidade funciona de um ponto a outro sem defeito. O produto passa pelo teste DIARIAMENTE.
Depuração
	Ocorre como consequência de um teste bem-sucedido. Isto é, quando um caso de teste descobre um erro, a depuração é o processo que resulta na remoção do erro.
	A depuração não é teste, mas frequentemente ocorre em consequência do teste.
	Existem 3 estratégias de depuração:
Força bruta
Rastreamento
Eliminação da causa
Gestão de Configuração de Software (SCM)
	É a arte de identificar, organizar e controlar modificações no software que está sendo criado por uma equipe de programação. O objetivo é maximizar a produtividade minimizando os erros.
	É um conjunto de atividades que foram desenvolvidas para gerenciar alterações através de todo o ciclo de vida de um software. A SCM pode ser vista como uma atividade de garantia de qualidade do software aplicada através de todo o processo de software.
	A gestão de configuração de software (SCM) é uma atividade do tipo “Guarda-chuva”, aplicada através de toda a gestão de qualidade. 
	As atividades SCM são desenvolvidas para (1) identificar a alteração, (2) controlar a alteração, (3)assegurar que a alteração esteja sendo implementada corretamente e (4) relatar as alterações a outros interessados.
	A diferença entre suporte de software e gestão de configuração de software. Suporte de software é um conjunto de atividades de engenharia que ocorrem depois que o software foi fornecido ao cliente e posto em operação. Gestão de configuração é um conjunto de atividades de rastreamento e controle iniciadas quando um projeto de engenharia de software começa e termina apenas quando o software sai de operação.
	No contexto da engenharia de software, uma referência é um marco no desenvolvimento de software. Uma referência é marcada pelo fornecimento de um ou mais itens de configuração de software que foram aprovados em consequência de uma revisão técnica. Por exemplo, os elementos de um modelo de projeto foram documentados e revisados. Erros foram encontrados e corrigidos. Uma vez que todas as partes do modelo foram revisadas, corrigidas e então aprovadas, o modelo do projeto torna-se uma referência.
	O repositório de SCM é um conjunto de mecanismos e estrutura de dados que permitem a uma equipe de software gerenciar alterações de maneira eficaz. Além disso, o repositório de SCM proporciona umcentralizador (HUB) para a integração das ferramentas de software, está no centro do fluxo do processo de software e pode impor estrutura e formato uniformes para os artefatos.
	O processo de gestão de configuração de software define uma série de tarefas que têm quatro objetivos primários: (1)identificar todos os itens que coletivamente definem a configuração do software, (2)gerenciar alterações de um ou mais desses itens, (3)facilitar a construção de diferentes versões de uma aplicação e (4) assegurar que a qualidade do software seja mantida à medida que a configuração evolui co’m o tempo.
	As camadas do processo de gestão de configuração de software são: identificação,controle de alteração, controle de versão, auditoria de configuração e relatos.
Métricas de Produto
Podem-se usar medidas para melhorar o entendimento dos atributos dos modelos criados e para avaliar a qualidade dos produtos ou sistemas construídos.
Medição é o processo pelo qual números ou símbolos são anexados aos atributos de entidades no mundo real para defini-los de acordo com regras claramente estabelecidas.
	Podem proporcionar uma maneira sistemática de avaliar a qualidade com base em um conjunto de regras claramente definidas. Elas também proporcionam uma visão objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e corrigir problemas potenciais antes que se tornem defeitos catastróficos.
	Métrica é uma medida quantitativa do grau como o qual um sistema, componente ou processo possui determinado atributo.
	Quando é coletado um único ponto de dado (por exemplo, o número de erros descobertos em um componente de software), foi estabelecida uma medida. A medição ocorre como resultado da coleção de um ou mais pontos de dados (por exemplo, um conjunto de revisões de componente e testes de unidade são investigados para coletar medidas do número de erros para cada um). Uma métrica de software relaciona as medidas individuais de alguma maneira (por exemplo, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade). 
Métricas para o Modelo de Requisitos
	Essas métricas examinam o modelo de requisitos com a intenção de prever o “tamanho” do sistema resultante.
Métricas baseadas em função
	A métrica ponto de função (FP) pode ser usada efetivamente como um meio para medir a funcionalidade fornecida por um sistema.
	A métrica FP pode ser empregada para (1) estimar o custo ou trabalho necessário para projetar, codificar e testar o software; (2) prever o número de erros que serão encontrados durante o teste; e (3) prever o número de componentes e/ou número de linhas projetadas de código-fonte no sistema implementado.
	Valores do domínio de informações são definidos da seguinte maneira:
Número de entradas externas: cada entrada externa é originada de um usuário ou transmitida de outra aplicação e fornece dados distintos orientados a aplicação ou informações de controle.
Número de saídas externas:cada sápida externa é formada por dados derivados da aplicação e fornece informações para o usuário.
Número de consultas externas: uma consulta externa é definida como uma entrada on-line que resulta na geração de alguma resposta imediata do software na forma de uma saída on-line.
Número de arquivos lógicos internos:cada arquivo lógico interno é um agrupamento lógico de dados que reside dentro das fronteiras do aplicativo e é mantido através de entradas externas.
Número de arquivos de interface externos:cada arquivo de interface externo é um agrupamento lógico de dados que reside fora da aplicação, mas fornece informações que podem ser usadas pela aplicação.
Métricas para o Modelo de Projeto
Métricas de projeto de arquitetura
	Essas métricas são uma “caixa-preta” no sentido de que elas não requerem qualquer conhecimento do funcionamento interno de um determinado componente de software.
	Existem 3 medidas de complexidade de projeto de software: complexidade estrutural, complexidade de dados e complexidade de sistema.
Métricas para projeto orientado a objeto
	As métricas de produto para sistemas orientados a objeto podem ser aplicadas não só ao modelo de projeto, mas também ao modelo de requisitos.
	Nove características distintas e mensuráveis de um projeto orientado a objeto:
Tamanho
Complexidade
Acoplamento
Suficiência
Totalidade
Coesão
Originalidade
Similaridade
Volatilidade
Conceitos de Gerenciamento de Projeto
Métricas de Processo e Projeto
	Medições podem ser aplicadas ao processo de software com a intenção de melhoria contínua. As medições podem ser usadas durante um projeto para ajudar nas estimativas, controle de qualidade, produtividade e controle de projeto. Finalmente, a medição pode ser usada pelos engenheiros de software para ajudar a avaliar a qualidade dos artefatos e auxiliar na tomada de decisões táticas na medida em que o projeto evolui.
	Seu propósito é avaliar alguma coisa. A partir dela, podemos ter o entendimento da eficácia de algumas situações, como do processo de software.
	 A medição é uma ferramenta de gerenciamento.
Métricas de Processo
	São coletadas através de todos os projetos e sobre longos períodos de tempo. Sua finalidade é proporcionar uma série de indicadores de processo que levam à melhoria do processo de software no longo prazo.
	O processo está no centro do triângulo que conecta três fatores que possuem uma profunda influência sobre a qualidade do software e desempenho organizacional: Produto, Pessoas e Tecnologia.
	Só pode medir a eficácia de um processo de software indiretamente. Isto é, você cria uma série de métricas baseadas nos resultados que podem ser obtidos do processo. Também pode obter métricas de processo medindo as características de tarefas específicas de engenharia de software.
Métrica de Projeto
	Permitem ao gerente de projeto de software (1) avaliar o estado de um projeto em andamento, (2) rastrear os riscos em potencial, (3) descobrir áreas problemáticas antes que elas se tornem “críticas”, (4) ajustar o fluxo de trabalho ou tarefas, e (5) avaliar a habilidade da equipe de projeto para controlar a qualidade dos produtos finais de software.
	Diferentemente das métricas de processo de software que são usadas para fins estratégicos, as medidas de projeto de software são táticas. Isto é, métricas de projeto e os indicadores derivados delas são usados por um gerente de projeto e uma equipe de software para adaptar o fluxo de trabalho do projeto e as atividades técnicas.
	Na medida em que o software evolui dos requisitos para o projeto, métricas técnicas são coletadas para avaliar a qualidade do projeto e fornecer indicadores que terão influência na abordagem adotada para geração de código e teste.
	Os objetivos das métricas de projeto são: usadas para minimizar o cronograma de desenvolvimento fazendo os ajustes necessários para evitar atrasos e mitigar problemas e riscos em potencial. E são usadas para avaliar a qualidade do produto de forma contínua e, quando necessário, modificar a abordagem técnica para melhorar a qualidade.
Medidas de Software
	As métricas de software OU métricas de produtividade podem ser classificadas em:
Medidas diretas: incluem custos e trabalho aplicado. Medidas diretas do produto incluem linhas de código (Line of code – LOC – Linhas de código) produzidas, velocidade de execução, tamanho de memória e defeitos relatados durante um determinado período de tempo.
Medidas indiretas: incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibil idade, e muitas outras “ades”. 
Métricas para Qualidade de Software
	Podem-se usar medidas para avaliar a quantidade dos requisitos e modelos de projeto, o código-fonte, e os casos de testes que foram criados enquanto o software é desenvolvido.
	Algumas medidas de qualidade de software:
Correção: um programa deve operar corretamente ou terá pouca utilidade para seus usuários. A correção é o grau com o qual o software executa sua função.
Manutenibilidade: é a facilidade com a qual um programa pode ser corrigido se for encontrado um erro, adaptado se o ambiente mudar, ou melhorado se o cliente desejar uma alteração nos requisitos.
Integridade: mede a habilidade de um sistema em resistir aos ataques à sua segurança.
Usabilidade: se um programa não for fácil de usar, muitas vezes ele está destinado ao fracasso, mesmo que as funções que ele executa sejam valiosas. A usabilidade é uma tentativa de quantificar a facilidade de uso.
Uma métrica de qualidade que traz benefícios tanto para o projeto quanto para o processo é a eficiência na remoção de defeitos (DRE). Essencialmente, a DRE é uma medida da habilidadede filtragem das ações de garantia de qualidade e controle quando elas são aplicadas através de todas as atividades da estrutura de processo. Também pode ser usada no projeto para avaliar a habilidade de uma equipe para encontrar erros antes que eles passem para a próxima atividade na estrutura do software.
	As linhas de base das métricas consistem em dados coletados de projetos de desenvolvimento de software do passado e pode ser tão simples, ou tão complexas quanto uma abrangente base de dados contendo dezenas de medidas de projeto e métricas delas derivadas.
Estimativas de Projeto de Software
	Antes de iniciar o projeto, a equipe de software deverá fazer uma estimativa do trabalho, os recursos que serão necessários e o tempo necessário para a sua conclusão. Uma vez executadas essas atividades, a equipe de projeto deverá estabelecer um cronograma que defina as tarefas de engenharia de software e as metas, deverá identificar os responsáveis pela execução de cada tarefa e especificar as dependências entre as tarefas que podem ter forte influência no progresso do trabalho.
Escopo e Viabilidade do Software
	O escopo do software descreve as funções e características que devem ser fornecidas aos usuários finais; os dados que entram e saem; o “conteúdo” que é apresentado aos usuários como consequência do uso de software; e o desempenho, restrições, interfaces e confiabilidade que limitam o sistema.
Recursos
	As 3 principais categorias de recursos de engenharia de software – pessoas, componentes de software reutilizáveis e o ambiente de desenvolvimento.
	 A engenharia baseada em componentes enfatiza a reusabilidade – isto é, a criação e reutilização de blocos básicos (ou, Componentes) de software. Quatro tipos de componentes:
Componentes de prateleira: software existente que pode ser adquirido de terceiros ou de projetos anteriores.
Componentes totalmente testados: os membros da equipe de software atual têm experiência plena na área de aplicação representada por esses componentes. Portanto, as modificações necessárias em componentes totalmente testados apresentarão um risco relativamente baixo.
Componentes parcialmente testados: os membros da equipe de software atual têm uma experiência limitada na área de aplicações representada por esses componentes. Portanto, as modificações necessárias para componentes parcialmente testados terão um grau razoável de risco.
Técnicas de Decomposição
	Existem quatro tipos diferentes para o problema do dimensionamento:
Dimensionamento de “Lógica nebulosa”: essa abordagem usa técnicas de raciocínio lógico aproximado, a pedra fundamental da lógica nebulosa. Para utilizá-la, o planejador deve identificar o tipo de aplicação, estabelecer sua magnitude em um escala qualitativa e então refinar a magnitude dentro do intervalo original.
Dimensionamento de pontos de função: o planejador desenvolve estimativas das características do domínio da informação (exemplos: números de entradas e saídas, de consultas externas e arquivos lógicos e internos).
Dimensionamento de componentes-padrão: o software é composto por uma série de diferentes “componentes-padrão” que são genéricos em relação a determinada área de aplicação. Por exemplo, os componentes-padrão para um sistema de informações são subsistemas, módulos, telas, relatórios, programas interativos, programas em lote, arquivos, LOC e instruções de nível. O planejador do projeto estima o número de ocorrências de cada componente-padrão e usa dados históricos de projeto para estimar o tamanho de cada um deles.
Dimensionamento de alteração: essa abordagem é empregada quando um projeto abrange o uso de software existente que deve ser modificado de alguma forma com parte do projeto. O planejador estima o número e tipo (por exemplo, reutilização, adição de código, mudança de código, exclusão de código) de modificações que devem ser feitas.
Os resultados de cada uma dessas abordagens de dimensionamento sejam combinados estatisticamente para criar uma estimativa de três pontos ou valores esperado.
Estimativa baseada em problema
	Estimativas LOC e FP são distintas. No entanto, ambas têm muitas características em comum. Inicia-se com uma definição delimitada do escopo do software e daí tenta-se decompor a definição em funções de problemas que podem ser estimados individualmente,
	As técnicas LOC e FP diferem em nível de detalhe requerido para a decomposição e no alvo do particionamento. Quando é usada a LOC como variável de estimativa, a decomposição é absolutamente essencial e muitas vezes são adotadas com níveis consideráveis de detalhes. Quanto maior o grau de particionamento, maior a probabilidade de serem desenvolvidas estimativas LOC razoavelmente precisas.
	Para estimativas FP, a decomposição funciona de forma diferente. Em vez de focalizar-se na função, é estimada cada uma das características do domínio de informação – entradas, saídas, arquivos de dados, consultas e interfaces externas – bem como os 14 valores de ajuste de complexidade.
Estimativas baseadas em processo
	O processo é decomposto em um conjunto relativamente pequeno de tarefas, e é estimado o trabalho necessário para executar cada tarefa. A estimativa começa com um delineamento das funções de software obtidas do escopo do projeto.
Modelos Empíricos de estimativa
Modelo COCOMO
O modelo utiliza pontos de objetos, uma medida indireta de software calculada por meio de contagens dos números de tela, relatórios e componentes que podem ser necessários para construir a aplicação. 
Trata das seguintes áreas:	
Modelo de composição de aplicação: usado durante os primeiros estágios da engenharia de software, em que o protótipo das interfaces de usuário, a consideração da interação de software e sistema, a avaliação do desempenho e a avaliação da maturidade da tecnologia são de uma importância.
Modelo de estágio do inicio do projeto: usado quando os requisitos tiverem sido estabilizados e a arquitetura básica de software tiver sido estabelecida.
Modelo de estágio pós-arquitetura: usado durante a construção do software.
Gestão de Risco
	Quando se considera risco no contexto da engenharia de software, os três fundamentos estão sempre em evidencia: Futuro: quais riscos podem fazer o projeto dar errado? Alteração: como as alterações nos requisitos do cliente, nas tecnologias de desenvolvimento, nos ambientes-alvo e todas as outras entidades conectadas ao projeto afetam a cadência e o sucesso geral? Escolhas: que métodos e ferramentas devem ser usados, quantas pessoas deverão ser envolvidas, quanta ênfase na qualidade seria suficiente?
Estratégicas de risco Reativa X Proativa
	Estratégia reativa monitora o projeto à procura de riscos prováveis. São reservados recursos para enfrentar riscos, caso se tornem problemas reais. Normalmente, a equipe de software não faz nada sobre os riscos até que alguma coisa dê errado. Desse modo, a equipe corre na tentativa de corrigir o problema rapidamente.
	Estratégia proativa considerada mais inteligente para o gerenciamento de risco. Inicia muito antes que o trabalho técnico comece. São identificados os riscos potenciais, avalia-se a probabilidade e o impacto, e os riscos são classificados por ordem de importância. Então, a equipe de software estabelece um plano para gerenciar o risco. O objetivo primário é evitar o risco, mas como nem todos os riscos podem ser evitados, o grupo trabalha para desenvolver um plano de contingência que lhe permita responder de maneira controlada e eficaz.
Riscos de software
	As diferentes categorias de riscos são:
Riscos de projeto: ameaçam o plano do projeto. Isto é, se os riscos do projeto se tornarem reais, são possíveis que o cronograma fique atrasado e os custos aumentem. Os riscos de projeto identificam problemas potenciais de orçamento, cronograma, pessoal, recursos, clientes e requisitos e seu impacto sobre o projeto de software.
Riscos técnicos: ameaçam a qualidade e a data de entrega do software a ser produzido. Se um risco técnico potencial