Universidade Presbiteriana Mackenzie

Faculdade de Computação e Informática

Introdução à Engenharia de Software

• Aula 03
Processo de Software
 O processo de software
• Conjunto estruturado de atividades, procedimentos,
artefatos e ferramentas necessários para o
desenvolvimento de um sistema de software
– Atividades
• Especificação, Projeto, Validação, Evolução
– Exemplos
• Processo Unificado (RUP), Programação Extrema, ...
• Um modelo de processo de software:
– Descreve um processo de uma perspectiva particular
– Normalmente foca em algumas atividades
 Modelos genéricos de processo de
software
• Modelo Cascata
– Fases separadas e distintas de especificação e desenvolvimento
• ES baseada em Componentes
– O sistema é montado a partir de componentes existentes
• Desenvolvimento Iterativo
– O sistema é desenvolvido através de várias etapas
• Existem muitas variantes destes modelos
– Por exemplo: Desenvolvimento formal onde um processo
semelhante ao cascata é usado, mas a especificação formal é
refinada durante os vários estágios para um projeto
implementável
Modelo Cascata
 Modelo Cascata
• Fases
– Definição de requisitos
– Projeto de sistema e software
– Implementação e teste de unidade
– Integração e teste de sistema
– Operação e manutenção
• Primeiro modelo a organizar as atividades de
desenvolvimento
• Uma fase tem de estar completa para iniciar a próxima
– Saídas das fases são acordadas contratualmente
• Todas as fases envolvem atividades de validação
 Problemas do Modelo Cascata
• Na prática, uma fase anterior nunca é refeita
– Dificuldade de responder às mudança
• Toda documentação deve estar finalizada antes de ir
para a próxima fase
• Funciona apenas quando os requisitos são bem
compreendidos e quando as mudanças são raras
– Poucos sistemas de negócio têm requisitos estáveis
• O modelo cascata é mais adequado em projetos de
Engenharia de Sistemas
• O cliente só vê o sistema no final do processo
 ES baseada em componentes
• Baseado em reuso sistemático onde sistemas são
integrados a partir de componentes existentes
• Estágios do processo
– Análise de componentes
– Modificação de requisitos
– Projeto de sistema com reuso
– Desenvolvimento e integração
• Esta abordagem está se tornando cada vez mais usada à
medida que padrões de componentes têm surgido
• Reuso acidental vs. Reuso planejado
 Processos Iterativos
• Requisitos de sistema sempre evoluem no curso de
um projeto
– Algum retrabalho é necessário
• A abordagem iterativa pode ser aplicada a qualquer
um dos modelos genéricos do processo
• Duas abordagens (relacionadas)
– Entrega incremental
– Desenvolvimento espiral
 Entrega incremental
• O sistema é entregue ao cliente em incrementos
– Cada incremento fornece parte da funcionalidade
• Os requisitos são priorizados
– Requisitos de prioridade mais alta são incluídos nos
incrementos iniciais
• Uma vez que o desenvolvimento de um incremento é
iniciado, os requisitos são congelados
– Os requisitos para os incrementos posteriores podem
continuar evoluindo (e incluir requisitos já implementados)
 Desenvolvimento incremental
Definir Atribuir Projetar a
requisitos requisitos aos arquitetura
iniciais incrementos do sistema

Desenvolver
Validar Integrar Validar
incremento
incremento incremento sistema
do sistema
Sistema
fina
Sistema incompleto
 Vantagens do desenvolvimento
incremental
• Incrementos podem ser entregues regularmente ao
cliente e, desse modo, a funcionalidade de sistema é
disponibilizada mais cedo
• Os incrementos iniciais agem como protótipos para
elucidar os requisitos para incrementos posteriores
do sistema
• Menor risco de falha geral do projeto
• Os serviços de sistema de mais alta prioridade
tendem a receber mais testes
 eXtreme Programming (XP)
• Uma abordagem baseada no desenvolvimento e na
entrega de incrementos de funcionalidade muito
pequenos
• Baseia-se no aprimoramento constante do código,
em testes automatizados, no envolvimento do
usuário na equipe e no desenvolvimento em pares
 Desenvolvimento espiral
• O processo é representado como uma espiral ao invés de
uma sequência de atividades com realimentação
• Cada loop na espiral representa uma fase no processo
• Sem fases definidas, tais como especificação ou projeto
– Os loops na espiral são escolhidos dependendo do que é
requisitado
• Os riscos são explicitamente avaliados e resolvidos ao
longo do processo
Modelo espiral do processo de
software
 Setores do modelo espiral
• Definição de objetivos
– Os objetivos específicos para a fase são identificados
• Avaliação e redução de riscos
– Riscos são avaliados e atividades são realizadas para reduzir os
riscos-chave
• Desenvolvimento e validação
– Um modelo de desenvolvimento para o sistema, que pode ser
qualquer um dos modelos genéricos, é escolhido
• Planejamento
– O projeto é revisado e a próxima fase da espiral é planejada
• Processo de Desenvolvimento vs. Processo de
Gerenciamento
 Atividades de um processo de
desenvolvimento
• Especificação de software
• Projeto e implementação de software
• Validação de software
• Evolução de software
 Especificação de software
• Processo para definir quais serviços são necessários
e identificar as restrições de operação e de
desenvolvimento do sistema
• Processo de engenharia de requisitos
– Estudo de viabilidade
• Realizado antes do projeto ser iniciado
– Elucidação e análise de requisitos
– Especificação de requisitos
– Validação de requisitos
 O processo de engenharia de
requisitos

Elucidação e
Estudo de Especificação Validação de
análise de
viabilidade de requisitos requisitos
requisitos

Relatório de Modelos de Detalhamento Documento de

viabilidade sistema de Requisitos Requisitos
Projeto e implementação de software
• Processo de converter a especificação num sistema
de software
• Projeto de software
– Projetar uma estrutura de software que atenda à
especificação
• Implementação de software
– Transformar essa estrutura em um programa executável
• As atividades de projeto e implementação estão
fortemente relacionadas e podem ser intercaladas
 Atividades do processo de projeto
• Projeto de arquitetura
• Especificação abstrata
• Projeto de interfaces entre componentes
• Projeto de componente
• Projeto de estrutura de dados
• Projeto de algoritmo
 Métodos estruturados
• Abordagens sistemáticas para projetar sistemas de
software
– Gerenciamento vs. Desenvolvimento
• O projeto é, em geral, documentado como um conjunto
de modelos gráficos
• Modelos possíveis
– Modelo de objeto
– Modelo de sequência
– Modelo de transição de estado
– Modelo estruturado
– Modelo de fluxo de dados
 Programação e depuração
• É a transformação de um projeto em um programa e
a remoção de defeitos desse programa
• Programação é uma atividade pessoal
– Não há processo genérico de programação
– Porém, há algumas práticas “consideradas boas”
• Programadores realizam alguns testes para descobrir
defeitos no programa e removem esses defeitos no
processo de depuração
 Validação de software
• Verificação e validação (V&V) têm a intenção de mostrar
que um sistema está em conformidade com a sua
especificação e que atende aos requisitos do cliente
• Verificação
– “Construímos o sistema corretamente?”
• Validação
– “Construímos o sistema correto?”
• Testes
– Execução do sistema com casos de teste que são derivados da
especificação do sistema e dos dados reais
 Tipos de teste
• Teste de componente ou unidade
– Os componentes individuais são testados
independentemente
– Esses componentes podem ser funções ou classes de
objetos, ou grupos coerentes dessas entidades
• Teste de sistema
– Teste de sistema como um todo
• Teste de aceitação
– Teste com dados do cliente para verificar se o sistema
atende às suas necessidades
 Evolução de software
• O software é inerentemente flexível e pode mudar
– Requisitos mudam devido a diversos fatores e o software
deve acompanhar essas mudanças
• Processos e métodos iterativos (XP, RUP, Espiral)
normalmente não fazem uma separação explícita
entre desenvolvimento de evolução
• Evolução pode ocorrer devido várias razões
– Correções (patches)
– Mudanças de requisitos
– Melhoria de funcionalidades pré-existentes
 Evolução de software

Definir Avaliar Propor

Modificar
requisitos de sistemas mudanças de
sistemas
sistema existentes sistema

Sistemas Sistema
existentes Modificado
 O Processo Unificado
(RUP –Rational UnifiedProcess)
• É um processo baseado na UML
– Tenta cobrir todos os aspectos do desenvolvimento de
software
• Fortemente focado na documentação do sistema
• Normalmente descrito a partir de três perspectivas
– Dinâmica: mostra as fases ao longo do tempo
– Estática: mostra atividades de processo
– Prática: sugere bons princípios e práticas de
desenvolvimento
Modelo de fases do RUP
 Fases do RUP
• Concepção
– Estabelecer o domínio de negócio para o sistema
• Elaboração
– Desenvolver um entendimento do domínio do problema e
a arquitetura do sistema
• Construção
– Projeto, programação e teste de sistema
• Transição
– Implantar o sistema no seu ambiente operacional
 Boas práticas do RUP
• Desenvolver o software iterativamente
• Gerenciar requisitos
• Usar arquiteturas baseadas em componentes
• Modelar o software visualmente
• Verificar a qualidade de software
• Controlar as mudanças do software
 Workflows estáticos
• Modelagem de Negócios:
– Processos de negócios são modelados.
• Requisitos
– Trata principalmente da definição formal do problema,
necessidades, características e requisitos do sistema.
• Análise e Design (ou Análise e Projeto)
– Modelos de arquitetura, de casos de uso, de componente, de
objeto e de sequência são criados e documentados.
1. Sugestão de arquitetura
2. Refinamento da arquitetura analisando os comportamentos (casos
de uso) para projetar componentes e o banco de dados do sistema.
– Concentra-se na fase de Elaboração e refinada na Construção.
 Workflows estáticos
• Implementação
– Maior concentração na Construção, mas presente na:
• Concepção: protótipos podem facilitar o entendimento dos
requisitos.
• Elaboração: esboços da arquitetura podem evoluir até que um
nível satisfatório seja alcançado.
• Transição: correções de falhas e ajustes no sistema são frequentes.
– Os subsistemas são construídos em incrementos e
integrados nos ciclos.
• A cada nova integração, os componentes individuais são testados,
e existe um refinamento dos artefatos construídos, se necessário.
• A geração automática, comum em ferramentas CASE, também
pode ser utilizada neste momento.
 Workflows estáticos
• Teste
– Maior concentração na Construção.
– Iterativo aplicada em conjunto com a implementação.
– O teste do sistema segue o término da implementação.
– Planejados para definir o foco e o esforço adequado de teste.
• Implantação
– Uma versão do produto é distribuída
– Maior concentração nas fases de Construção e Transição
– O teste de aceitação também precisa ser considerado.
– Artefatos como material de apoio precisam ser disponibilizados.
 Workflows estáticos
• Gerenciamento de Configuração e Mudanças
– Gerencia as mudanças do sistema.
• Gerenciar Solicitações de Mudanças,
• Gerenciar Baselines e Entregáveis
• Gerencia o CCB - Configuration Control Board
– Apesar de apoiar todo o projeto, possui mais demanda na
Construção e Transição.
• Gerenciamento de Projetos
– Apenas PMI não basta para gerir projetos de software
– Deve ser utilizado em todas as fases.
• Ambiente
– Relacionado à disponibilização de ferramentas de software
apropriadas para a equipe de desenvolvimento
 Suporte ao processo automatizado
(CASE)
• ES auxiliada por computador (CASE - Computer-Aided
Software Engineering)
• Automação da atividade
– Editores gráficos para o desenvolvimento de modelos de
sistema
– Dicionário de dados para gerenciar entidades de projeto
– Construtor Gráfico para a construção de interface para
usuário
– Depuradores para suportar detecção de falhas no sistema
– Tradutores automáticos para gerar novas versões de um
programa
 Tecnologia Case
• A tecnologia Case tem levado a melhorias
significantes no processo de software
• Porém o processo requer pensamento criativo e
experiência de todos os envolvidos nas etapas de
desenvolvimento
– A melhor ferramenta CASE existente não irá fazer o
trabalho de um grupo despreparado
 CASE classificação
• Ajuda a entender os diferentes tipos de ferramentas
de CASE e seu suporte para atividades do processo
• Perspectiva Funcional
– As ferramentas são classificadas de acordo com suas
funções específicas
• Perspectiva do Processo
– As ferramentas são classificadas de acordo com as
atividades do processo que suportam
• Perspectiva da Integração
– As ferramentas são classificadas de acordo com sua
organização em unidades integradas
 Classificação das Ferramentas
(Funcional)
Tipo de Ferramenta
Ferramentas de planejamento
Ferramentas de edição
Ferramentas de prototipação
Ferramentas de processamento
de linguagem
Ferramentas de análise de
programas
Ferramentas de testes
Ferramentas de documentação
Ferramentas de reengenharia
Exemplos
Ferramentas de estimativa, planilhas de cálculo
Editores de texto, editores de diagramas
Linguagens de muito alto nível, geradores de
interfaces com usuário
Compiladores, interpretadores
Geradores de referências cruzadas, analisadores
estáticos, analisadores dinâmicos
Geradores de dados de testes, comparadores de
arquivos
Editores de imagens, programas de layout de
páginas
Sistemas de referência cruzada, sistemas de
reestruturação de programas
 Classificação das Ferramentas
(Atividade)
Ferramentas Especi- Projeto Implemen- Verificação
ficação tação e Validação
Reengenharia *
Testes * *
Depuração * *
Análise de programas * *
Processamento de linguagem * *
Prototipação * *
Gerenciamento de configuração * *
Documentação * * * *
Edição * * * *
Planejamento * * * *
 Perspectiva de Integração CASE
• Ferramentas
– Suporta tarefas individuais do processo como verificação
da consistência de um projeto, edição de texto, etc
• Workbenches
– Suporte a fases do processo como especificação ou projeto
– Normalmente inclui uma variedade de ferramentas
integradas
• Ambientes
– Suporta tudo ou uma parte substancial de todo um
processo de software
– Normalmente inclui várias áreas de trabalho integradas
Ferramentas, workbenches e
ambientes
 Universidade Presbiteriana Mackenzie
Escola de Engenharia
São Paulo - SP

Obrigado!