Resumo de Desenvolvimento de Software_unidade 1b

Prévia do material em texto

Resumo de Desenvolvimento de Software – unidade 1b
1 - Modelos de Desenvolvimento de Software
– Processo de Desenvolvimento de Software
O modelo Cascata (Clássico)
Um dos primeiros modelos (Royce, 1970). 
O desenvolvimento de um estágio deve terminar antes do próximo começar.
Simples, mas não reflete, efetivamente, o modo como o código é desenvolvido.
Derivado do mundo do hardware (linhas de montagens).
Engenharia de Sistemas
Software faz parte de um sistema maior.
Estabelecer os requisitos básicos para todos os elementos que envolvem o software, como hardware, pessoas e bancos de dados.
Envolve a coleta dos requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível.
Exige uma intensa comunicação entre o cliente e o analista.
Faz parte da Analise de Sistema.
Análise dos Requisitos
Intensifica-se o processo de coleta dos requisitos;
Identificar as funções necessárias, o desempenho e interfaces exigidos. (funcionalidades e restrições). 
Os requisitos para o sistema e para o software são documentados e revistos com o cliente.
Produz a especificação dos requisitos.
Faz parte da Analise de Sistema.
Projeto
Traduz os requisitos em um conjunto de representações que podem ser avaliadas quando à qualidade. 
Estrutura de dados; 
Arquitetura do software; 
Detalhes Procedimentais; 
Caracterização da interface.
É avaliado antes de começar a ser implementado;
Junto com as etapas anteriores torna-se parte da documentação do sistema.
Codificação
Projeto traduzido para a linguagem do computador (C, Java).
Se o projeto for executado detalhadamente, a codificação pode ser executada mecanicamente?
Testes
Concentra-se nos aspectos funcionais externos e lógicos internos do software.
Garante que “todas as instruções” tenham sido testadas.
A entrada definida produz os resultados exigidos
Manutenção
Software embutido nem sempre tem esta parte;
Provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente.
Tipos de Manutenção
Manutenção Corretiva: diagnóstico e correção de erros
Manutenção Adaptativa: adaptação do software para acomodar mudanças em seu ambiente externo.
Manutenção Perfectiva: exigência do cliente para acréscimos funcionais e de desempenho.
Manutenção Preventiva: melhorar a confiabilidade e manutenibilidade futura (técnicas de engenharia reversa e reengenharia).
Problemas
O mais antigo e amplamente usado.
Projetos reais raramente seguem o fluxo sequencial que ele propõe.
Ocorrem iterações que trazem problemas na aplicação do paradigma.
É difícil para o cliente declarar todas as exigências explicitamente.
É difícil acomodar as incertezas naturais que existem no começo de muitos projetos.
O cliente deve ter paciência. Uma versão do software só estará disponível em um ponto tardio do cronograma.
Um erro crasso pode ser desastroso.
Desenvolvedores Ociosos.
Só é apropriado quando os requisitos são bem conhecidos.
Desenvolvimento Evolucionário
Ideia básica: Desenvolvimento de implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado seja desenvolvido. 
a) Desenvolvimento Exploratório – O desenvolvimento se inicia com as partes do sistema que são compreendidas. O sistema evolui com o acréscimo de novas características, à medida em que elas são propostas pelo cliente. 
b) Protótipos descartáveis – Conhecer os requisitos e partir disso, desenvolver uma melhor definição dos requisitos para o sistema. O protótipo se concentra em fazer experimentos com partes dos requisitos que estejam mal compreendidos.
A especificação pode ser desenvolvida gradativamente.
RAD (Rapid Application Development)
Adaptação do sequencial (Cascata).
Modelo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento bastante curto (60 a 90 dias).
Adaptação de alta velocidade do modelo sequencial linear.
A “alta velocidade” é conseguida através de uma abordagem de construção baseada em componentes.
Trabalha com aplicações modularizadas de forma que essas funções possam ser equipes RAD distintas.
Desenvolvimento em equipe (team) e modular.
Fases: Modelagem do Negócio, Modelagem dos Dados, Modelagem do Processo, Geração da Aplicação, Teste e Implantação.
Formal
Semelhanças com o Modelo Cascata.
A especificação de requisitos de software é redefinida em uma especificação formal detalhada, que é expressa em uma notação matemática.
Os processos de desenvolvimento de projeto, implementação e teste de unidade são substituídos por um processo de desenvolvimento transformacional, em que a especificação formal é refinada por meio de uma série de transformações, em um programa.
Desenvolvimento orientado a reuso
Ampla base de componentes de software que pode ser acessados
Componentes possuem infraestrutura de integração
Alguns são sistemas propriamente ditos (COTS – Comercial Of The Shelf)
Estágio inicial de especificação e o de validação são comparáveis aos outros processos
Reduz a quantidade de software a ser desenvolvido - custos - riscos ????
Entrega mais rápida
Controle de versões de componentes
Obs.: Na maioria dos projetos de software há algum reuso de software Engenharia de Software com base em componentes.
Modelos de Processo de Software Genéricos
Desenvolvimento Incremental: quando as fases da especificação, projeto e implementação de software são desdobradas em uma série de estágios, que são, por sua vez desenvolvidos.
Desenvolvimento em Espiral: quando o desenvolvimento do sistema evolui a partir de um esboço inicial, em direção ao sistema final desenvolvido.
Desenvolvimento Incremental
Cascata - comprometimento com um conjunto de requisitos específicos.
Evolucionário - Requisitos e decisões de projeto sejam postergados.
Incremental - Abordagem intermediária que combina as vantagens de ambos
os modelos.
Utiliza elementos do modelo sequencial linear com a filosofia interativa da prototipagem.
Cliente identifica em um esboço, as funções a serem fornecidas pelo sistema - priorizam-se as funções - definem-se série de estágios de entrega – cada estagio fornece um conjunto de funcionalidade do sistema.
Modelo Espiral
Acrescenta aspectos gerenciais ao processo de desenvolvimento de software.
Análise de riscos em intervalos regulares do processo de desenvolvimento de software
Planejamento
Controle
Tomada de decisão
O processo é representado como uma espiral em vez de uma sequencia de atividades.
Cada volta na espiral representa uma fase no processo.
Não há fases fixas como especificação ou projeto - voltas na espiral são escolhidas dependendo do que é requerido. 
Riscos são avaliados explicitamente e resolvidos ao longo do processo. 
O Modelo em espiral é um modelo incremental.
Este tipo de modelo combina elementos do modelo cascata (aplicado repetidamente) com a filosofia iterativa da prototipação.
Acrescenta mais uma atividade: Análise de Risco.
O objetivo é trabalhar junto do usuário para descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido.
O desenvolvimento começa com as partes do produto que são mais bem entendidas.
A evolução acontece quando novas características são adicionadas à medida que são sugeridas pelo usuário.
A cada iteração é desenvolvido uma versão usável, não um protótipo.
	
Modelo Espiral – Ciclo Espiral típico
1. Identificação dos:
a) Objetivos : Performance; Funcionalidades; Mudanças, etc.
b) Meios alternativos de implementação: Projeto A; Projeto B; Reuso; Compra, etc.
c) Restrições: Custos; Interfaces; Prazos, etc.
2. Identificar áreas de incerteza.
a) Avaliar as alternativas relativas aos objetivos e restrições.
b) Normalmente nesta etapa são identificadas áreas de incerteza que serão fontes significantes do projeto de risco.
3. Formulação de uma estratégia de custo efetiva para resolver as origens do risco. – Isto deve envolver prototipação,simulação,questionários, etc.
4. Determinar riscos relativos restantes.
a) Risco de performance ou interface:
Desenvolvimento evolucionário;
Esforço mínimo para especificação;
Planejamento para o próximo nível de prototipação;
Desenvolvimento de um protótipo mais detalhado para;
Desenvolvimento de um protótipo mais detalhado para continuar a resolver os assuntos de maior risco.
b) Protótipo é operacionalmente útil e robusto:
Serie de evolucionários protótipos
c) Prototipação resolveu os riscos:
O próximo passo é seguir o básico enfoque cascata,modificado tanto quanto necessário para incorporar o desenvolvimento incremental.
Fornece o potencial para desenvolvimento rápido de versões incrementais do software.
Nas primeiras iterações são desenvolvido versões que podem ser protótipos.
Nas iterações mais adiantadas são produzido versões incrementais mais completas e melhoradas.
É uma abordagem realística para o desenvolvimento de software em grande escala;
Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva;
Pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável;
Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso.
1 - Planejamento: 
Determinação dos objetivos, alternativas e restrições; 
Comunicação com os clientes; 
Definição de Recursos.
2 - Análise de Risco: 
Análise das alternativas e identificação / resolução dos riscos.
3 - Construção: 
Desenvolvimento do produto no nível seguinte; 
Constrói protótipos ou versões mais avançadas do produto; 
Realiza Testes, implantação, suporte.
4 - Avaliação do cliente: 
Obter um feedback do cliente baseado na avaliação da versão do software; 
São levantado as necessidades de mudança para o software.
Processo Unificado
Conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software.
ESTRUTURA* genérica de processo que pode ser customizado adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos recursos disponíveis para um projeto.
Framework* – Captura a funcionalidade comum a várias aplicações.
Framework: padrão de arquitetura que fornece um template extensível
para aplicações em um domínio.
Template (ou "modelo de documento") é um documento de conteúdo, com apenas a apresentação visual (apenas cabeçalhos por exemplo) e instruções sobre onde e qual tipo de conteúdo deve entrar a cada parcela da apresentação - por exemplo conteúdos que podem aparecer no início e conteúdos que só podem aparecer no final.
a) Processo Unificado da Rational (RUP): Versão especializada do processo unificado que adiciona elementos à estrutura genérica.
b) Processo Unificado – Pode-se apresentar também como:
O processo “oficial” definido para apoiar o uso da UML
A partir do sucesso da UML, surge como padrão de fato para a especificação de software.
A UML é independente de processo.
É possível utilizá-la, com vários processos de Engenharia de Software.
O RUP consiste em uma UML e Processo
O RUP consiste em uma maneira de desenvolvimento de software iterativa, centrada à arquitetura e guiada por casos de uso, sendo uma abordagem de ciclo de vida, especialmente adequada à UML.
O RUP é um processo de engenharia de software bem definido e bem estruturado que define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las.
O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão.