O documento discute os problemas no desenvolvimento de software e práticas recomendadas para resolvê-los. Os principais problemas incluem: metodologias inadequadas, gerenciamento de processo deficiente e softwares que mudaram de perfil. As práticas recomendadas são: desenvolvimento iterativo, gerenciamento de requisitos, arquiteturas baseadas em componentes, modelagem visual, controle de qualidade e gerenciamento de mudanças. Essas práticas permitem maior sucesso de projetos, melhor qualidade e menor custo.
O documento descreve os principais aspectos do Rational Unified Process (RUP), incluindo suas seis melhores práticas: desenvolver software iterativamente, gerenciar requisitos, usar arquitetura baseada em componentes, modelar visualmente o software, verificar continuamente a qualidade do software e controlar mudanças no software. O RUP fornece um guia para as atividades de desenvolvimento de software de forma iterativa e centrada em arquitetura.
O documento descreve o Rational Unified Process (RUP), um processo de engenharia de software que utiliza uma abordagem iterativa e orientada a objetos. O RUP é dividido em quatro fases principais (concepção, elaboração, construção e transição) e nove disciplinas agrupadas em disciplinas de engenharia e disciplinas de apoio. A disciplina de modelagem de negócios é a primeira das seis disciplinas de engenharia e tem como objetivo estabelecer uma compreensão do negócio e dos requisitos do cliente.
O documento apresenta os conceitos fundamentais de engenharia de software, incluindo: (1) engenharia de software é o estudo sistemático do desenvolvimento de software; (2) qualidade de software envolve atributos como manutenibilidade, desempenho e usabilidade; (3) a crise de software ocorre devido à complexidade dos sistemas e falta de qualificação.
O documento introduz os conceitos de qualidade de software, discutindo o que é qualidade, qualidade de software e qualidade do processo versus qualidade do produto. Também aborda normas, verificação, validação, gerência de configuração e sistemas de controle de versão como elementos relacionados à qualidade de software.
Este documento apresenta uma aula introdutória sobre engenharia de software. Ele discute o objetivo da disciplina, o que é software e engenharia de software, características e objetivos da engenharia de software, qualidade de software, a crise do software e atividades e artefatos relacionados à engenharia de software.
Gerenciamento do ciclo de vida de software com o Visual Studio Team System.
Apresentação baseada em material oficial da Microsoft para apresentação da ferramenta na empresa que trabalho.
O documento descreve os principais aspectos do Rational Unified Process (RUP), incluindo suas seis melhores práticas: desenvolver software iterativamente, gerenciar requisitos, usar arquitetura baseada em componentes, modelar visualmente o software, verificar continuamente a qualidade do software e controlar mudanças no software. O RUP fornece um guia para as atividades de desenvolvimento de software de forma iterativa e centrada em arquitetura.
O documento descreve o Rational Unified Process (RUP), um processo de engenharia de software que utiliza uma abordagem iterativa e orientada a objetos. O RUP é dividido em quatro fases principais (concepção, elaboração, construção e transição) e nove disciplinas agrupadas em disciplinas de engenharia e disciplinas de apoio. A disciplina de modelagem de negócios é a primeira das seis disciplinas de engenharia e tem como objetivo estabelecer uma compreensão do negócio e dos requisitos do cliente.
O documento apresenta os conceitos fundamentais de engenharia de software, incluindo: (1) engenharia de software é o estudo sistemático do desenvolvimento de software; (2) qualidade de software envolve atributos como manutenibilidade, desempenho e usabilidade; (3) a crise de software ocorre devido à complexidade dos sistemas e falta de qualificação.
O documento introduz os conceitos de qualidade de software, discutindo o que é qualidade, qualidade de software e qualidade do processo versus qualidade do produto. Também aborda normas, verificação, validação, gerência de configuração e sistemas de controle de versão como elementos relacionados à qualidade de software.
Este documento apresenta uma aula introdutória sobre engenharia de software. Ele discute o objetivo da disciplina, o que é software e engenharia de software, características e objetivos da engenharia de software, qualidade de software, a crise do software e atividades e artefatos relacionados à engenharia de software.
Gerenciamento do ciclo de vida de software com o Visual Studio Team System.
Apresentação baseada em material oficial da Microsoft para apresentação da ferramenta na empresa que trabalho.
O documento discute processos de engenharia de software, incluindo modelos de processo como cascata, incremental e orientado a reuso. Ele também descreve atividades-chave como especificação, projeto, implementação, validação e evolução. Além disso, aborda técnicas para lidar com mudanças como prototipação, entrega incremental e o modelo espiral de Boehm, bem como o Rational Unified Process.
O documento discute os métodos ágeis e o gerenciamento do ciclo de vida de aplicações (ALM), apresentando os desafios comuns em projetos de software, as fases do ALM e as disciplinas envolvidas.
Gerenciamento do ciclo de vida de software com o Visual Studio Team System.
Apresentação baseada em material oficial da Microsoft para apresentação da ferramenta na empresa que trabalho. Adicionei algumas possibilidades como o template do SCRUM da Conchando e a integração das Team Builds com o Final Builder.
O artigo discute a importância da rastreabilidade de requisitos para a qualidade do software, apresentando dois modelos de referência para apoiar a definição do modelo de rastreabilidade. O documento também aborda como a rastreabilidade interfere na qualidade do produto e como os requisitos são gerenciados ao longo do processo de desenvolvimento.
Este documento fornece um resumo de três frases ou menos sobre a gestão do desenvolvimento de software para a web:
1) A internet requer equilíbrio entre flexibilidade e metodologia disciplinada devido à competição, ciclos de vida curtos e necessidade de entregar valor rapidamente.
2) Métodos ágeis como Scrum e Extreme Programming são mais adequados do que modelos tradicionais devido à necessidade de feedback frequente do cliente e liberações frequentes.
3) Projetos para a web diferem em seu escopo e requisitos depend
1) O documento apresenta as qualificações e experiência de Luiz Barboza na área de qualidade de software e serviços.
2) A ementa da disciplina aborda conceitos de qualidade de produto e processo de software, modelos de qualidade e aspectos da qualidade na prestação de serviços.
3) Os objetivos são introduzir conceitos de qualidade de software e serviços para a comercialização de sistemas de informação.
O documento descreve o IBM Rational Unified Process (RUP), um processo proprietário de engenharia de software criado pela Rational Software Corporation e agora de propriedade da IBM. O RUP usa uma abordagem orientada a objetos e é projetado para aumentar a produtividade das equipes de desenvolvimento de software. Ele define linhas mestras, fases e princípios como gestão de requisitos, uso de arquitetura baseada em componentes e modelagem visual para guiar o desenvolvimento de software.
O documento discute vários conceitos fundamentais de engenharia de software, incluindo: 1) a definição de software vai além de apenas programas e inclui documentação e dados; 2) existem dois tipos de produtos de software - genéricos e sob encomenda; 3) a engenharia de software surgiu para lidar com sistemas complexos e atualmente abrange uma variedade maior de produtos.
O documento discute processos de desenvolvimento de software, incluindo modelos como cascata e desenvolvimento incremental. Também aborda atividades como especificação, projeto, implementação, validação e evolução. Explica como prototipação e entrega incremental podem lidar melhor com mudanças nos requisitos.
Este documento fornece um resumo da metodologia de desenvolvimento de software chamada Feature Driven Development (FDD). A FDD combina as melhores práticas de gerenciamento ágil de projetos com uma abordagem orientada a objetos. Ela consiste em cinco fases principais: desenvolver um modelo abrangente, construir uma lista de funcionalidades, planejar por funcionalidade e detalhar e construir por funcionalidade. A FDD enfatiza o trabalho em equipe, a propriedade individual de classes e o desenvolvimento incremental focado em funcionalidades valiosas para o cliente.
Gerenciamento da Qualidade de Software 2.pptxRoberto Nunes
O documento discute a importância da qualidade de software e as técnicas para gerenciamento da qualidade, incluindo CMM, CMMI, MPS.BR e testes. A qualidade é essencial para a competitividade e requer processos bem definidos ao longo de todo o ciclo de desenvolvimento.
Este documento discute a qualidade de software, abordando os principais motivos de falha em projetos de software, normas e modelos de qualidade, qualidade do processo e do produto de software, e testes de software. Ele fornece estatísticas sobre falhas em projetos de software, fatores que levam ao fracasso, e características de qualidade de produtos de software de acordo com a norma brasileira.
Metodologia de Desenvolvimento de SoftwaresAragon Vieira
A metodologia de desenvolvimento de software descrita enfatiza o desenvolvimento iterativo e incremental com foco na entrega rápida de valor ao usuário final, utilizando princípios ágeis como envolvimento do usuário, entregas frequentes e feedback constante.
O documento descreve os principais tópicos do SWEBOK, que é um guia para a engenharia de software. Ele cobre 11 áreas de conhecimento, incluindo requisitos, projeto, construção, teste, manutenção e gerenciamento de projetos de software.
O documento discute processos de engenharia de software, qualidade de software, o modelo CMM e processos ágeis. Ele fornece definições de processos de software, qualidade de software e CMM, e descreve brevemente o RUP e referências bibliográficas.
(CONSTRUÇÃO2) Engenharia de Software_ADRIANA.pptxDVDGlash
O documento discute os fundamentos e considerações práticas da construção de software. Aborda tópicos como minimizar a complexidade, antecipar mudanças, construir para verificação, normas de construção, design de construção, linguagens de construção, codificação, testes, modelagem em V, reutilização, qualidade, integração e gestão da construção.
Este documento resume uma aula sobre processos de software. Apresenta conceitos como processo de software, modelos de processo de desenvolvimento de software, modelos de ciclo de vida como cascata e iterativos, além de linguagens, métodos e ferramentas CASE. O objetivo é introduzir os alunos aos principais elementos envolvidos no desenvolvimento de software.
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixCris Fidelix
O documento discute a evolução da preocupação com a qualidade de software ao longo dos anos, desde as décadas de 1950 a 2000. Nos anos iniciais, os erros eram conhecidos apenas após o término do programa. Nos anos 1970 surgiram análise estruturada e teste antes do término. Nos anos 1980 houve primeiras preocupações com padrões de qualidade. Nos anos 1990 surgiram primeiros processos de teste motivados pelo bug do milênio. Nos anos 2000, testes foram estruturados dentro do processo de desenvolvimento e surgiram ferramentas de
02 Introdução à engenharia de software - conceitos fundamentaisWaldemar Roberti
O documento discute os desafios da engenharia de software, incluindo a dificuldade de acompanhar a demanda por novos programas e manter programas existentes, a dependência da economia em software, e os altos custos de software, especialmente de manutenção.
Contenu connexe
Similaire à Análise e Design Orientado a Objetos.ppt
O documento discute processos de engenharia de software, incluindo modelos de processo como cascata, incremental e orientado a reuso. Ele também descreve atividades-chave como especificação, projeto, implementação, validação e evolução. Além disso, aborda técnicas para lidar com mudanças como prototipação, entrega incremental e o modelo espiral de Boehm, bem como o Rational Unified Process.
O documento discute os métodos ágeis e o gerenciamento do ciclo de vida de aplicações (ALM), apresentando os desafios comuns em projetos de software, as fases do ALM e as disciplinas envolvidas.
Gerenciamento do ciclo de vida de software com o Visual Studio Team System.
Apresentação baseada em material oficial da Microsoft para apresentação da ferramenta na empresa que trabalho. Adicionei algumas possibilidades como o template do SCRUM da Conchando e a integração das Team Builds com o Final Builder.
O artigo discute a importância da rastreabilidade de requisitos para a qualidade do software, apresentando dois modelos de referência para apoiar a definição do modelo de rastreabilidade. O documento também aborda como a rastreabilidade interfere na qualidade do produto e como os requisitos são gerenciados ao longo do processo de desenvolvimento.
Este documento fornece um resumo de três frases ou menos sobre a gestão do desenvolvimento de software para a web:
1) A internet requer equilíbrio entre flexibilidade e metodologia disciplinada devido à competição, ciclos de vida curtos e necessidade de entregar valor rapidamente.
2) Métodos ágeis como Scrum e Extreme Programming são mais adequados do que modelos tradicionais devido à necessidade de feedback frequente do cliente e liberações frequentes.
3) Projetos para a web diferem em seu escopo e requisitos depend
1) O documento apresenta as qualificações e experiência de Luiz Barboza na área de qualidade de software e serviços.
2) A ementa da disciplina aborda conceitos de qualidade de produto e processo de software, modelos de qualidade e aspectos da qualidade na prestação de serviços.
3) Os objetivos são introduzir conceitos de qualidade de software e serviços para a comercialização de sistemas de informação.
O documento descreve o IBM Rational Unified Process (RUP), um processo proprietário de engenharia de software criado pela Rational Software Corporation e agora de propriedade da IBM. O RUP usa uma abordagem orientada a objetos e é projetado para aumentar a produtividade das equipes de desenvolvimento de software. Ele define linhas mestras, fases e princípios como gestão de requisitos, uso de arquitetura baseada em componentes e modelagem visual para guiar o desenvolvimento de software.
O documento discute vários conceitos fundamentais de engenharia de software, incluindo: 1) a definição de software vai além de apenas programas e inclui documentação e dados; 2) existem dois tipos de produtos de software - genéricos e sob encomenda; 3) a engenharia de software surgiu para lidar com sistemas complexos e atualmente abrange uma variedade maior de produtos.
O documento discute processos de desenvolvimento de software, incluindo modelos como cascata e desenvolvimento incremental. Também aborda atividades como especificação, projeto, implementação, validação e evolução. Explica como prototipação e entrega incremental podem lidar melhor com mudanças nos requisitos.
Este documento fornece um resumo da metodologia de desenvolvimento de software chamada Feature Driven Development (FDD). A FDD combina as melhores práticas de gerenciamento ágil de projetos com uma abordagem orientada a objetos. Ela consiste em cinco fases principais: desenvolver um modelo abrangente, construir uma lista de funcionalidades, planejar por funcionalidade e detalhar e construir por funcionalidade. A FDD enfatiza o trabalho em equipe, a propriedade individual de classes e o desenvolvimento incremental focado em funcionalidades valiosas para o cliente.
Gerenciamento da Qualidade de Software 2.pptxRoberto Nunes
O documento discute a importância da qualidade de software e as técnicas para gerenciamento da qualidade, incluindo CMM, CMMI, MPS.BR e testes. A qualidade é essencial para a competitividade e requer processos bem definidos ao longo de todo o ciclo de desenvolvimento.
Este documento discute a qualidade de software, abordando os principais motivos de falha em projetos de software, normas e modelos de qualidade, qualidade do processo e do produto de software, e testes de software. Ele fornece estatísticas sobre falhas em projetos de software, fatores que levam ao fracasso, e características de qualidade de produtos de software de acordo com a norma brasileira.
Metodologia de Desenvolvimento de SoftwaresAragon Vieira
A metodologia de desenvolvimento de software descrita enfatiza o desenvolvimento iterativo e incremental com foco na entrega rápida de valor ao usuário final, utilizando princípios ágeis como envolvimento do usuário, entregas frequentes e feedback constante.
O documento descreve os principais tópicos do SWEBOK, que é um guia para a engenharia de software. Ele cobre 11 áreas de conhecimento, incluindo requisitos, projeto, construção, teste, manutenção e gerenciamento de projetos de software.
O documento discute processos de engenharia de software, qualidade de software, o modelo CMM e processos ágeis. Ele fornece definições de processos de software, qualidade de software e CMM, e descreve brevemente o RUP e referências bibliográficas.
(CONSTRUÇÃO2) Engenharia de Software_ADRIANA.pptxDVDGlash
O documento discute os fundamentos e considerações práticas da construção de software. Aborda tópicos como minimizar a complexidade, antecipar mudanças, construir para verificação, normas de construção, design de construção, linguagens de construção, codificação, testes, modelagem em V, reutilização, qualidade, integração e gestão da construção.
Este documento resume uma aula sobre processos de software. Apresenta conceitos como processo de software, modelos de processo de desenvolvimento de software, modelos de ciclo de vida como cascata e iterativos, além de linguagens, métodos e ferramentas CASE. O objetivo é introduzir os alunos aos principais elementos envolvidos no desenvolvimento de software.
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixCris Fidelix
O documento discute a evolução da preocupação com a qualidade de software ao longo dos anos, desde as décadas de 1950 a 2000. Nos anos iniciais, os erros eram conhecidos apenas após o término do programa. Nos anos 1970 surgiram análise estruturada e teste antes do término. Nos anos 1980 houve primeiras preocupações com padrões de qualidade. Nos anos 1990 surgiram primeiros processos de teste motivados pelo bug do milênio. Nos anos 2000, testes foram estruturados dentro do processo de desenvolvimento e surgiram ferramentas de
02 Introdução à engenharia de software - conceitos fundamentaisWaldemar Roberti
O documento discute os desafios da engenharia de software, incluindo a dificuldade de acompanhar a demanda por novos programas e manter programas existentes, a dependência da economia em software, e os altos custos de software, especialmente de manutenção.
Similaire à Análise e Design Orientado a Objetos.ppt (20)
02 Introdução à engenharia de software - conceitos fundamentais
Análise e Design Orientado a Objetos.ppt
1. Aula 1 – Práticas Recomendadas
na Engenharia de Software
FEEC-UNICAMP
Ricardo Gudwin
Ivan Ricarte
Mário Jino
2. Análise da Situação Atual no
Desenvolvimento de Software
Economia Mundial
crescentemente dependente de software
Mercado de Software
demanda mais produtividade e qualidade em menos tempo
Aplicações de Software
expandindo em tamanho, complexidade e disseminação
Mão de Obra Qualificada
cada vez mais difícil de encontrar
Gerenciamento de Equipes de Desenvolvimento
equipes numerosas
indivíduos especializados, distribuídos geograficamente
rápida mudança nas tecnologias disponíveis
3. Sintomas de Problemas no
Desenvolvimento de Software
Necessidades dos usuários não atendidas
Mudanças nos requisitos não implementadas
Módulos que não conseguem interagir adequadamente
Programas de difícil manutenção
Descoberta tardia de erros sérios no projeto
Baixa qualidade do software
Desempenho inaceitával do software
Equipes de desenvolvimento sem compromissos com o
projeto
incapazes de rastrear os passos do desenvolvimento
Processos de desenvolvimento não confiáveis
build and release
4. Causas dos Problemas no
Desenvolvimento de Software
Gerenciamento de Requisitos inadequado
Comunicações imprecisas e/ou ambíguas
Arquiteturas Inflexíveis (inadequadas a mudanças)
Complexidade incontrolável e avassaladora
Inconsistências não detectadas durante a especificação
de requisitos, análise, design ou implementação
Testes insuficientes
Falta de referência na estimativa do estado do projeto
Gerenciamento de Risco comprometido devido a um
desenvolvimento do tipo cascata (waterfall)
Propagação de mudanças sem o controle adequado
Falta de automação no processo de desenvolvimento
5. Sumário dos Problemas
Por que isso acontece ?
Metodologia de Desenvolvimento (Processo) inadequado
Gerenciamento do Processo de Desenvolvimento inadequado
Por que inadequados ?
O perfil do software mudou
O que fazer para resolver ?
Adotar (criar, desenvolver) novas metodologias e novas
formas de gerenciamento
Como desenvolver essas novas metodologias
Observar os projetos de software que deram certo
Tentar capturar os princípios que fizeram com que eles dessem
certo
Tentar reproduzir as decisões que se mostraram promissoras
6. Práticas Consagradas da
Engenharia de Software
Práticas “que deram certo” em projetos de software
Desenvolvimento Iterativo
Gerenciamento dos Requisitos
Arquiteturas baseadas em Componentes
Modelagem Visual do Software
Controle de Qualidade do Software
Gerenciamento de Mudanças
Resultados
mais projetos concluídos com sucesso
gerenciamento adequado de grandes equipes de software
qualidade do software melhorada
diminuição dos custos de desenvolvimento
7. Desenvolvimento de Software
Iterativo
Por quê ?
O primeiro design muito provavelmente será deficiente com
respeito aos requisitos principais do projeto
nem todos os requisitos são claramente identificáveis a princípio, e
aqueles que são podem as vezes ser ambíguos ou simplesmente
inconsistentes
requisitos podem mudar ou ficar obsoletos
• clientes podem mudar de opinião
• mercado competitivo pode exigir mudanças
A descoberta tardia de defeitos no design resultarão em
aumentos de custos ou cancelamento do projeto
O tempo e o dinheiro gastos na correção de um design
defeituoso não são recuperáveis !
8. Desenvolvimento do Tipo
Cascata e Redução de Risco
Especificação
de Requisitos
Análise
Design
Implementação
Teste
Tempo
Risco
9. Desenvolvimento Iterativo
Aplicação da Cascata Iterativamente ao Sistema
Primeiras iterações carregam os maiores riscos
Cada iteração gera uma versão executável com algum
incremento ao sistema
Cada iteração inclui integração e testes
R
A
D
I
T tempo
R
A
D
I
T
R
A
D
I
T
R
A
D
I
T
I1 I2 I3 I4
10. Redução de Risco no
Desenvolvimento Iterativo
Tempo
Risco
Cascata
Iterativo
Iteração Iteração Iteração Iteração Iteração Iteração Iteração Iteração
11. Gerenciamento de Requisitos
Requisitos são dinâmicos
devemos esperar que eles mudem durante o desenvolvimento
de um software
Objetivo
elicitar, organizar e documentar as funcionalidades e restrições
necessárias
Mudanças nos Requisitos
não podem ser impedidas, mas devem ser gerenciadas
avaliação das mudanças necessárias e determinação de seu
impacto no projeto - relação custo/benefício
acompanhar e documentar as mudanças, as decisões tomadas e
suas consequências
12. Documentação dos Requisitos
Especificação dos Requisitos
documentada de forma clara e explícita
Por que ?
Nem sempre poderemos ter um acesso direto ao cliente a todas
as horas
Clientes podem mudar de idéia e se não há nada registrado a
respeito dos requisitos …
Ligado a vários outros elementos do projeto
design e implementação, teste e qualidade, gerência do projeto
Requisitos
capturados em uma forma que seja inteligível tanto ao cliente
como à equipe de desenvolvimento
meta para a equipe de desenvolvimento
critério de aceitação e validação por parte do cliente
13. Arquitetura Baseada em
Componentes
Arquitetura de Software
abrange decisões significativas relativas à organização de um
sistema de software
Seleção dos elementos estruturais que irão compor o sistema e
suas interfaces
Comportamento do sistema especificado como uma colaboração
entre esses elementos
Composição destes elementos estruturais e comportamentais em
sub-sistemas progressivamente maiores
Estilo arquitetural que dirige a organização, os elementos e suas
interfaces, suas interações e colaborações, bem como sua
composição
escolha da arquitetura tem um impacto crucial na capacidade do
sistema de evoluir, se modificar e se integrar com outros
sistemas
14. Arquitetura Baseada em
Componentes
Requisitos Arquiteturais
uso, funcionalidade, desempenho, flexibilidade, capacidade de
reutilização, compreensibilidade, aspectos econômicos e tecnológicos,
aspecto estético
Boas Arquiteturas
flexíveis e baseadas em componentes
Arquitetura Flexível
facilidade de manutenção, extensão e reuso
permite a divisão de trabalho entre elementos da equipe de
desenvolvimento
encapsula detalhes do hardware e dependências do sistema
Arquitetura Baseada em Componentes
Reutilização e customização de componentes existentes
Escolha dentre milhares de componentes comercialmente disponíveis
Permitem a evolução incremental do software existente
15. Modelagem Visual do Software
Características
captura a estrutura e comportamento de arquiteturas e
componentes
mostra como os elementos se agregam entre si
esconde ou expõe detalhes, quando apropriado a uma tarefa
mantém a consistência entre um design e sua implementação
promove a comunicação entre elementos da equipe sem
ambiguidades
aumentam a capacidade de gerenciamento da complexidade do
software
Modelo
simplificação da realidade que provê uma descrição completa do
sistema a partir de uma perspectiva em particular
16. Modelagem Visual do Software
Linguagem de Modelagem
Linguagem Visual - Diagramas
O que é UML (Unified Modeling Language)
linguagem visual de modelagem para especificar, visualizar,
construir e documentar as partes de um sistema de software,
durante todas as fases de desenvolvimento do mesmo
adotada como uma norma para modelagem de software (OMG)
independente de plataforma ou linguagem de implementação
Diferentes tipos de diagramas
Diagramas de Casos de Uso, diagramas de Classes, diagramas
de objetos, diagramas de estados, diagramas de componentes,
diagramas de deployment, diagramas de colaboração,
diagramas de sequência e diagramas de atividades
17. Modelagem Visual de Software
Ferramentas CASE
permitem a criação de modelos visuais usando o UML
requisitos diferenciais:
sincronização com o código fonte
engenharia reversa
revisão das mudanças efetuadas no código fonte
Revisão das Mudanças e Gerenciamento de Mudanças
durante a sincronização do código fonte, a ferramenta pode
detectar automaticamente as mudanças e solicitar que o usuário
confirme se elas estão corretas
caso as mudanças sejam efetuadas, elas devem ser registradas
no modelo visual e no registro de mudanças
18. Verificação da
Qualidade do Software
Qualidade
“a característica de ter demonstrado, após a produção de um
produto, produzido de acordo com um processo previamente
acordado, o sucesso em atingir ou exceder os requisitos
previamente acordados, de acordo com os critérios de medição
previamente acordados”
Atingir ou superar os requisitos
Estabelecimento de métricas para demonstrar que os requisitos
foram atingidos
Implementação de um Processo de desenvolvimento que
garanta um nível de qualidade repetível e gerenciável
Teste de Software
alto custo e grandes deficiências, na maioria das organizações
19. Verificação da
Qualidade do Software
Desenvolvimento Iterativo
Permite que o sistema seja continuamente testado e debugado
Distribui a tarefa de teste em doses mais administráveis
Erros são encontrados mais cedo no ciclo de vida do software,
quando os custos para sua correção são menores
Automação dos Testes
Ferramentas computacionais podem ser utilizadas para
automatizar parte dos testes de um sistema
Essas ferramentas devem ser utilizadas desde as primeiras
iterações
Os primeiros testes devem compreender os módulos
isoladamente
Posteriormente, quando os módulos são integrados, deve ser
feito um teste de integração
20. Dimensões da Qualidade de
Software
Tipo Por que ? Como ?
Confiabilidade Descobrir condições de
crash no sistema
Ferramentas de Análise e
Instrumentação do Código
Funcionalidade Descobrir se o sistema
cumpre os requisitos
Casos de Teste para cada
cenário implementado
Desempenho
dos Módulos
Descobrir se o
desempenho do módulo é
aceitável
Verificar o desempenho para
cada caso de uso ou cenário
implementado
Desempenho
do Sistema
Descobrir se o sistema
como um todo tem bom
desempenho, quando em
carga de produção
Testando o desempenho de
todos os casos de uso em
condições de carga nominal e
em pior-caso
21. Gerenciamento de Mudanças
Mudanças devem ser controladas
como e quando elas são introduzidas
quem as introduziu
sincronização das mudanças entre as diferentes equipes
participantes do projeto
Por que ?
Múltiplas equipes trabalhando simultaneamente em múltiplos
projetos, com múltiplas versões de múltiplos componentes
sem um controle disciplinado, o desenvolvimento se degrada
num verdadeiro caos
Problemas
atualizações simultâneas
notificação de atualizações inadequada
múltiplas versões
22. Gerenciamento de Mudanças
Práticas recomendáveis
decompor a arquitetura em subsistemas e atribuir a
responsabilidade de cada subsistema a uma equipe
estabelecer espaços de trabalhos seguros para cada
desenvolvedor
isolamento de mudanças feitas em outros espaços de trabalho
controle dos artefatos de software - modelos, código,
documentação, etc.
Estabelecer um espaço de trabalho de integração
Estabelecer um mecanismo de controle de mudanças necessário
ou seja, ninguém efetua mudanças sem passar pelo mecanismo
Saber que mudanças aparecem em que releases do software
Liberar um release testado do software a cada iteração
23. Processos de Desenvolvimento
de Software
Engenharia de Software
diversos processos de desenvolvimento de software
grande similaridade entre os processos
divergências em alguns detalhes
linguagens de modelagem diferentes
Exemplos de Processos
Processo Cascata (Waterfall)
Processo Schlaer-Mellor
Processo Microsoft (Build-and-Release)
Fusion
Syntropy
Catalysis
XP - Extreme Programming
24. O Processo Unified
Processo Unified
unificação das idéias de Jacobson, Rumbaugh e Booch
derivado e desenvolvido a partir do Objectory de Jacobson
desenvolvido para o UML e junto com o UML
instanciado na forma de um produto da Rational Corporation, o
RUP - Rational Unified Process
Uma definição em três tempos
direcionado por casos de uso
focalizado na arquitetura
iterativo e incremental
Baseado em Componentes
módulos de software interconectados por meio de interfaces
bem definidas
25. O Processo Unified
Direcionado por Casos de Uso
propósito de um software é servir a seus usuários
levantamento das necessidades dos usuários é feita por meio do
levantamento de casos de uso
Casos de Uso
Sequências de eventos envolvendo como protagonistas o
usuário (ou usuários) e o sistema
Captura dos requisitos por casos de uso substitui a tradicional
captura de funcionalidades e atributos de um sistema
A captura dos casos de uso direciona todo o processo de
desenvolvimento
especificação de casos de uso
design de casos de usos
casos de usos são implementados
casos de uso são utilizados para desenvolver os testes
26. O Processo Unified
Focalizado na Arquitetura
arquitetura: plano conceitual antevendo a construção de um
sistema
permite um desenvolvimento lógico antes do desenvolvimento
concreto
arquitetura é concebida em função das necessidades do usuário
influenciada por diversos fatores
plataforma de hardware, sistema operacional, protocolos de
comunicações, outros softwares com os quais deve se integrar,
módulos re-utilizáveis, considerações de distribuição, desempenho
e confiabilidade
definição de uma arquitetura se realiza na definição de sub-
sistemas que devem compor o sistema, os componentes,
classes e objetos que os compõem
27. O Processo Unified
Iterativo e Incremental
prevê um crescimento gradativo ao sistema
a cada iteração, novos casos de uso são agregados ao sistema,
equipando-o com novas funcionalidades ou modificando as
funcionalidades existentes
Ciclo de Vida
Concepção, Elaboração, Construção, Transição
Cada uma dessas fases
corresponde a várias iterações, onde cada iteração deve passar
pelas fases de especificação, análise, design, implementação e
testes
Dependendo da fase
ênfase na especificação, análise, design, implementação ou
testes pode variar
29. Desenvolvimento de
Software Ágil
Processos Ágeis de Desenvolvimento de Software
Agile Software Development Manifesto
Indivíduos e interações antes de processos e ferramentas
Um software funcionando, antes de uma documentação
compreensiva
Colaboração com o cliente, antes de uma negociação de contrato
Responder à necessidade de mudar, antes de seguir um plano
Por quê ?
Um software não é uma ponte nem uma casa
Custo de modelagem pode ser muito alto
Requisitos mudam constantemente
Adaptação pode ser uma estratégia melhor do que a predição
Um código documentado pode ser um modelo melhor do que
um diagrama
30. XP - Extreme Programming
http://www.extremeprogramming.org
31. XP – Extreme Programming
XP e o Processo Unified
Processo Unified é um processo ágil ?
Processo Unified é um Framework, não um processo
Pode ser customizado para diferentes tipos de projetos
Mínimo processo Unified ?
Casos de Usos e Diagramas de Classes
O Processo dX
Robert Martin -
http://www.objectmentor.com/publications/RUPvsXP.pdf