Aula de processos introdução de Software

Prof. Renan Assunção Chaves
PROCESSOS DE SOFTWARE

Agenda de Hoje
• Modelos de processo de software.
• Atividades de processo.
• Modelos de Processo

Processo de software
• “Um processo de software é um método para
desenvolver ou produzir software.
• A pesquisa em processo de software lida com
métodos e tecnologias estimativas, suporte e
melhoria das atividades de desenvolvimento de
software.
• Define quem faz o que, quando e como.

4
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
O processo de software
• Um conjunto estruturado de atividades necessárias para
desenvolver um sistema de software.
• Existem vários processos de desenvolvimento de software
diferentes mas todos envolvem:
• Um modelo de processo de desenvolvimento de software é
uma representação abstrata de um processo. Ele apresenta
uma descrição do processo de uma perspectiva em particular.
Especificação
Implementaçã
o
Validação Evolução

5
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Descrições de processo de software
• Quando descrevemos e discutimos processos, geralmente
falamos sobre as atividades desses processos, tais como
especificação de modelo de dados, desenvolvimento de
interface de usuário, etc. e organização dessas atividades.
• Descrições de processos também podem incluir:
• Produtos, que são os resultados de uma atividade do processo;
• Papéis, que refletem as responsabilidades das pessoas envolvidas
no processo;
• Pré e pós-condições, que são declarações que são verdadeiras
antes e depois de uma atividade do processo ser executada, ou um
produto produzido.

6
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Processos dirigidos a planos e ágeis
• Processos dirigidos a planos são processos em que todas as
atividades do processo são planejadas com antecedência e
o progresso é medido em relação a esse plano.
• Nos processos ágeis o planejamento é incremental e é mais
fácil modificar o processo para refletir alterações nos
requisitos do cliente.
• Na realidade, os processos mais práticos incluem elementos
dos processos ágeis e dirigidos a planos.
• Não existe processo de software certo ou errado.

Modelos
• Um modelo é uma simplificação da realidade.
• Planos de detalhes, podem ser estruturais (organização
do sistema) ou comportamentais (dinâmica do sistema)
• Modelos são construídos para permitir um melhor
entendimento sobre o sistema que está sendo
construído.
• especificar a estrutura e comportamento
• guia para construção do sistema
• documentam as decisões tomadas

Modelos
• Modelos de sistemas complexos são importantes
porque não temos capacidade de compreendê-
los inteiramente
• Os melhores modelos estão relacionados à
realidade (modelos simplificam a realidade)
• Nenhum modelo único é suficiente. Conjunto de
modelos independentes

Modelos de processo de software
• Uma representação simplificada de um processo
de software, apresentada de uma perspectiva
específica
• Exemplos de modelos de processo são:
• Workflow - sucessão de atividades
• Fluxo de Dados - fluxo de informação
• Papel/ação – representa os papéis das pessoas e as
atividades pelas quais elas são responsáveis.

Levantamento
Análise
Projeto
Implementaçã
o
Testes
O modelo cascata
Principais problemas:
 O cliente participa do projeto somente no
início e no final
 Os riscos são mitigados no final do projeto
 Tem descoberta tardia de erros de projeto

1
3
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Fases do modelo cascata
• Existem fases identificadas e separadas no modelo
cascata:
• O principal inconveniente do modelo cascata é a
dificuldade de acomodação de mudanças depois que o
processo já foi iniciado. Em princípio, uma fase precisa ser
completada antes de se mover para a próxima fase.
Análise e
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

O modelo iterativo
Iteração 1 Iteração 2 Iteração 3
Levantamento
Análise
Projeto
Implementação
Testes
Levantamento
Análise
Projeto
Implementação
Testes
Levantamento
Análise
Projeto
Implementação
Testes
Módulo 1 Módulo 2 Módulo 3

O modelo iterativo e incremental
Iteração 1 Iteração 2 Iteração 3
Levantamento
Análise
Projeto
Implementação
Testes
Levantamento
Análise
Projeto
Implementação
Testes
Levantamento
Análise
Projeto
Implementação
Testes
Módulo 1 Módulo 1 Módulo 2 Módulo 1
Módulo 2
M
ódulo
3

1
6
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
• O custo para acomodar mudanças nos requisitos do cliente é reduzido.
• A quantidade de análise e documentação que precisa ser feita é bem menor do que o
necessária no modelo cascata.
• É mais fácil obter feedback do cliente sobre o trabalho de
desenvolvimento que tem sido feito.
• Os clientes podem comentar demonstrações do software e ver quanto foi
implementado.
• Possibilidade de mais rapidez na entrega e implantação de software útil
para o cliente.
• Os clientes podem usar e obter ganhos do software mais cedo do que é possível no
processo cascata.
Benefícios do desenvolvimento incremental

1
7
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Problemas do desenvolvimento incremental
• O processo não é visível.
• Gerentes precisam de entregas regulares para medir o progresso. Se
os sistemas são desenvolvidos de forma rápida, não é viável do ponto
de vista do custo produzir documentação para refletir todas as
versões do sistema.
• A estrutura do sistema tende a degradar conforme novos
incrementos são adicionados.
• A menos que tempo e dinheiro sejam gastos na reconstrução para
melhorar o software, as mudanças regulares tendem a corromper a
estrutura do sistema. A incorporação posterior de mudanças no
software se torna progressivamente mais difícil e cara.

• Um protótipo é uma versão inicial de um sistema
usada para demonstrar conceitos e testar opções
de projeto.
• Um protótipo pode ser usado:
• No processo de engenharia de requisitos para ajudar
na elicitação e validação de requisitos;
• Nos processos de projeto para explorar opções e
desenvolver um projeto de interface de usuário;
• No processo de testes para executar testes fim-a-fim.
Protótipação rápida

Coleta e refinamento dos
requisitos
Refinamento do
protótipo
Engenharia do
produto
Projeto rápido
Construção do
protótipo
Avaliação do protótipo
pelo cliente
Fim
Início
Protótipação rápida

C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
2
0
Desenvolvimento de protótipos
• Pode ser baseado em linguagens ou ferramentas de
prototipagem rápida.
• A prototipação deve focar em áreas do produto que não são bem
entendidas;
• A checagem de erros e recuperação podem não estar incluídas no
protótipo;
• O foco deve ser em requisitos funcionais ao invés de não
funcionais como por exemplo, a confiabilidade e a segurança.
• Os protótipos devem ser descartados depois do
desenvolvimento, pois não são uma boa base para um
sistema em produção.
• Geralmente a estrutura do protótipo é degradada por
mudanças rápidas;

Modelo espiral - Boehm
• Segue a abordagem de passos sistemáticos do Ciclo de
Vida Clássico incorporando-os numa estrutura iterativa
que reflete mais realisticamente o mundo real
• Usa a Prototipação, em qualquer etapa da evolução do
produto, como mecanismo de redução de riscos.
• Cada loop na espiral representa uma fase do processo de
software, ou seja, não existem fases fixas.
• Engloba as melhores características do ciclo de vida
Clássico como o da Prototipação, adicionando um novo
elemento: a Análise Dos Riscos

2
3
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Setores do modelo espiral
O projeto é revisto
e a próxima fase
da espiral é
planejada.
Planejamento
Um modelo de
desenvolvimento
para o sistema é
escolhido, pode
ser qualquer um
dos modelos
genéricos.
Desenvolviment
o e validação
Os riscos são
avaliados e
atividades
executadas para
reduzir os
principais riscos.
Avaliação e
redução de
riscos
São identificados
os objetivos
específicos para
cada fase.
Definição de
objetivos

2
4
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
Pontos Importantes
• Os processos de software são as atividades envolvidas
na produção de um sistema de software. Os modelos de
processo de software são representações abstratas
desses processos.
• Modelos de processo gerais descrevem a organização
dos processos de software. Exemplos desses processos
gerais incluem o modelo 'cascata', desenvolvimento
incremental e desenvolvimento orientado a reuso.
• A engenharia de requisitos é o processo de desenvolver
uma especificação de software.

2
5
C
h
a
p
t
e
r
2
S
o
f
t
w
a
r
e
P
r
o
c
e
s
• Processos de projeto e implementação se preocupam em
transformar uma especificação de requisitos em um sistema
de software executável.
• A validação de software é o processo de checar se o
sistema está em conformidade com sua especificação e se
esse está de acordo com as necessidades reais do usuário
do sistema.
• A evolução de software ocorre quando você altera sistemas
de software existentes para adequá-los a novas
necessidades. O software precisa evoluir para continuar útil.
Pontos Importantes

Rational Unified Process
1. Histórico e Conceitos
2. Melhores práticas
3. Fases
4. Disciplinas

O RUP, Processo Unificado Racional é um processo proprietário de
Engenharia de software criado pela Rational Software Corporation,
adquirida pela IBM, ganhando um novo nome IRUP e tornando-se uma
brand na área de Software, fornecendo técnicas a serem seguidas pelos
membros da equipe de desenvolvimento de software com o objetivo de
aumentar a sua produtividade no processo de desenvolvimento.
O RUP usa a abordagem da orientação a objetos em sua concepção e é
projetado e documentado utilizando a notação UML (Unified Modeling
Language) para ilustrar os processos em ação. Utiliza técnicas e práticas
aprovadas comercialmente.

O RUP é, por si só, um produto de software. É modular e automatizado, e
toda a sua metodologia é apoiada por diversas ferramentas de
desenvolvimento integradas e vendidas pela IBM através de seus "Rational
Suites".
Métodos concorrentes no campo da engenharia de software incluem o
"Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a
Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiado por
Funcionalidades) entre outros.
Objetivo é assegurar a produção de software de alta qualidade dentro de
prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)

O RUP define perfeitamente quem é responsável pelo que, como as coisas
deverão ser feitas e quando devem ser realizadas, descrevendo todas as
metas de desenvolvimento especificamente para que sejam alcançadas.
Oferece uma abordagem organizada em disciplinas para atribuir tarefas
e responsabilidades dentro de uma organização de desenvolvimento.

Melhores Práticas
 Desenvolver software iterativamente
 Gestão de requisitos
 Uso de arquitetura baseada em componentes
 Uso de software de modelos visuais
 Verificação da qualidade do software
 Gestão e Controle de Mudanças do Software

Desenvolver Software Iterativamente
Desenvolver iterativamente significa desenvolver em ciclos. Cada ciclo é
contém um objetivo que deve ser alcançado (lançamento de um pré release
ou beta, correção de um bug, etc.)
Esta prática acaba dando ao RUP uma série de vantagens, como:
 Possibilidade de identificar/modificar requerimentos com mais
facilidade;
 Integração progressiva (quase continua) de elementos ao software,
ocasionando uma melhora no descobrimento e endereçamento de
riscos;
 Desenvolvimento iterativo provê aos gerentes maneiras de fazer
mudanças táticas aos produtos; etc.

Gestão de Requisitos
O gerenciamento de recursos acarreta um melhor controle sobre projetos
complexos, além de maior qualidade e redução de custos.
O RUP é uma metodologia dirigida-a-casos-de-uso (use-drivencase), de
modo que é possível utilizar os mesmos casos de uso definidos no sistema
como base para o resto do processo.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos de
artefatos dependentes do processo, que têm sido considerados muito mais
eficazes na captura de requisitos funcionais.

Arquitetura Baseada em
Componentes
Um componente normalmente se relaciona com um objeto na
programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de sistema,
focando-se em produzir uma arquitetura executável nas fases iniciais do
projeto, ou seja, antes de comprometer recursos em larga escala.
Estes componentes são normalmente incluídos em infraestruturas
existentes como o CORBA e o COM (Modelo de Componentes de
Objetos).

Uso de Software de Modelos Visuais
A modelagem visual permite melhor entender não só a concepção e a
complexidade do sistema, mas também “dimensionar” (no sentido de qual a
forma do sistema), além de facilitar a identificação e solução de problemas.

Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os
projetos de sistemas computacionais. Normalmente pensa-se em qualidade
de software após o término dos projetos, ou a qualidade é responsabilidade
de uma equipe diferente da equipe de desenvolvimento.
O RUP não toma a qualidade como responsabilidade de apenas uma
pessoa ou grupo, mas como uma responsabilidade de todos os integrantes
do projeto.
A qualidade é focada especialmente em duas áreas:
 Qualidade de produto: Sendo desenvolvido (software ou sistema) e
todos as partes envolvidas (componentes, subsistemas, arquitetura).
 Qualidade de processo: Dentro do projeto de desenvolvimento.

Gestão e Controle de Mudanças do
Software
Em todos os projetos de software a existência de mudanças é inevitável. O
RUP define métodos para controlar e monitorar mudanças. Como uma
pequena mudança pode afetar aplicações de formas inteiramente
imprevisíveis, o controle de mudanças é essencial para o sucesso de
um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um
programador que as mudanças efetuadas noutro sistema não afetarão o
seu sistema.

Fases de Desenvolvimento
Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer
do ciclo de vida de um projeto. As fases indicam a ênfase que é dada no
projeto em um dado instante. Para capturar a dimensão do tempo de um
projeto, o RUP divide o projeto em
quatro fases diferentes:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.

Fases de Desenvolvimento
O RUP também se baseia nos 4 Ps:
1. Pessoas
2. Projeto
3. Produto
4. Processo
As fases são compostas de iterações. As iterações são janelas de tempo;
as iterações possuem prazo definido enquanto as fases são objetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximas fases
e documentam o projeto, além de
permitir melhor acompanhamento.

Fase de Concepção
Esta fase do RUP abrange as tarefas de comunicação com o cliente e
planejamento.
É feito um plano de projeto avaliando os possíveis riscos, as estimativas de
custo e prazos, estabelecendo as prioridades, levantamento dos requisitos
do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das
partes interessadas na definição do escopo do projeto, onde são
examinados os objetivos para se decidir sobre a continuidade do
desenvolvimento.

Fase de Elaboração
Abrange a Modelagem do modelo genérico do processo.
O objetivo desta fase é analisar de forma mais detalhada a análise do
domínio do problema, revisando os riscos que o projeto pode sofrer e a
arquitetura do projeto começa a ter sua forma básica.
Indagações como “O plano do projeto é confiável?”, “Os custos são
admissíveis?” são esclarecidas nesta etapa.

Fase de Construção
Desenvolve ou Adquire os componentes de Software.
O principal objetivo desta fase é a construção do sistema de software, com
foco no desenvolvimento de componentes e outros recursos do sistema.
É na fase de Construção que a maior parte de codificação ocorre.

Fase de Transição
Abrange a entrega do software ao usuário e a fase de testes.
O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e
compreendido pelo usuário final.
As atividades desta fase incluem o treinamento dos usuários finais e
também a realização de testes da versão beta do sistema visando garantir
que o mesmo possua o nível adequado de qualidade.

Disciplinas
As disciplinas descrevem o aspecto estático do processo, como ele é
descrito em termos de componentes, disciplinas, atividades, fluxos de
trabalho, artefatos e papéis do processo. São divididas em:
 Seis Disciplinas de Engenharia
 Modelagem de Negócios
 Requisitos
 Análise e Projeto ("Design")
 Implementação
 Teste
 Implantação
 Três Disciplinas de Apoio/Suporte
 Ambiente
 Configuração e Gerência de Mudança
 Gerência de Projeto

Engenharia - Disciplina de Modelagem de Negócios
Modelagem de negócios, explica como descrever uma visão da organização
na qual o sistema será implantado e como usar esta visão como uma base
para descrever o processo, papéis e responsabilidades.
O objetivo de modelagem de negócios é, primeiramente, estabelecer uma
melhor compreensão e canal de comunicação entre engenharia de negócios
e engenharia de software. Compreender o negócio significa que os
engenheiros de software devem compreender a estrutura e a dinâmica da
empresa alvo (o cliente), os atuais problemas na organização e possíveis
melhorias.

Engenharia - Disciplina de Requisitos
Esta disciplina explica como levantar pedidos das partes interessadas
("stakeholders") e transformá-los em um conjunto de requisitos que os
produtos funcionam no âmbito do sistema a ser construído e fornecem
requisitos detalhados para o que deve fazer o sistema.

Engenharia - Disciplina de Análise e Projeto (“Design”)
O objetivo da análise e projeto é mostrar como o sistema vai ser realizado.
O objetivo é construir um sistema que:
 Execute as tarefas e funções especificadas nas descrições;
 Cumpra todas as suas necessidades;
 Seja fácil de manter quando ocorrerem mudanças de requisitos
funcionais.

Engenharia - Disciplina de Implementação
Os efeitos da implementação são:
 Para definir a organização do código, em termos de subsistemas de
implementação organizadas em camadas
 Para implementar classes e objetos em termos de componentes
(arquivos-fonte, binários, executáveis e outros)
 Para testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores individuais (ou
equipes), em um sistema executável

Engenharia - Disciplina de Teste
As finalidades da disciplina de teste são:
 Verificar a interação entre objetos
 Verificar a integração adequada dos componentes do software
 Verificar se todos os requisitos foram corretamente implementados
 Identificar e garantir que os defeitos são abordados antes da
implantação do software
 Garantir que todos os defeitos são corrigidos, reanalisados e fechados
O RUP propõe uma abordagem iterativa, o que significa que deve-se testar
todo o projeto. Os testes são realizados ao longo de 4 dimensões da
qualidade: Confiabilidade, Funcionalidade,
Desempenho da aplicação, e o Desempenho do sistema.

Engenharia - Disciplina de Implantação
O objetivo da implantação é o de produzir com sucesso lançamentos de
produtos e entregar o software para seus usuários finais.
Ele cobre uma vasta gama de atividades, incluindo a produção de releases
externos do software, a embalagem do software e aplicativos de negócios,
distribuição do software, instalação do software e prestação de ajuda e
assistência aos usuários.
Embora as atividades de implantação estejam principalmente centradas em
torno da fase de transição, muitas das atividades devem ser incluídas nas
fases anteriores para se preparar para a implantação, no final da fase de
construção.
Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm
menos detalhes do que outros workflows.

Apoio/Suporte - Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar o processo
para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizes de
apoio a um projeto.
A proposta das atividades de ambiente é prover à organização de
desenvolvimento de software os processos e as ferramentas que darão
suporte à equipe de desenvolvimento.
Se os usuários do RUP não entendem que o RUP é um framework de
processo, eles podem percebê-lo como um processo pesado e caro.

Apoio/Suporte - Disciplina de Configuração e
Gerência de Mudança
A disciplina de Gestão de Mudança em negócios com RUP abrange três
gerenciamentos específicos: de configuração, de solicitações de mudança,
e de status e medição.
A Rational também tem um produto para manter as solicitações de
mudança chamado ClearQuest.

Apoio/Suporte - Disciplina de Gerência de Projeto
Esta disciplina concentra-se principalmente sobre os aspectos importantes
de um processo de desenvolvimento iterativo:
Gestão de riscos; Planejamento de um projeto iterativo através do ciclo de
vida e para uma iteração particular; E o processo de acompanhamento de
um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta
cobrir todos os aspectos do gerenciamento de projetos. Por exemplo, não
abrange questões como:
 Gestão de Pessoas: contratação, treinamento, etc.
 Orçamento Geral: definição, alocação, etc.
 Gestão de Contratos: com fornecedores, clientes, etc.

Embora o RUP não seja um processo adequado a todos os tipos de
desenvolvimento de software, ele representa uma nova geração de
processos genéricos. A mais importante inovação é a separação de fases e
workflows, e o reconhecimento de que a implantação de software no
ambiente do usuário é parte do processo. As fases são dinâmicas e tem
objetivos. Os workflows são estáticos e constituem atividades técnicas que
não estão associadas a uma única fase, mas podem ser utilizados ao
longo do desenvolvimento para atingir os objetivos de cada fase
(Sommerville 2007, pág. 56).
Conclusão

DISCIPLINAS
Vamos agorar conhecer um pouco mais sobre as 6
disciplinas de engenharia do RUP:
Modelagem de Negócios
Requisitos
Análise e Projeto ("Design")
Implementação
Teste
Implantação

DISCIPLINA DE
MODELAGEM DE
NEGÓCIOS

É uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core
disciplines”. Dentro do ciclo de desenvolvimento de software podemos dizer
que essa é sem dúvida a disciplina menos praticada.
RUP não define esta como uma disciplina obrigatória, mas recomenda
fortemente que ela seja executada especialmente para empresas que estão
iniciando um novo negócio e não possuam uma clara modelagem do
negócio.

Finalidades:
 Entender os problemas da organização identificando as possíveis
melhorias;
 Avaliar o impacto de mudanças na organização;
 Assegurar que os clientes, usuários, desenvolvedores e outros
parceiros tenham uma compreensão comum da organização;
 Gerar conteúdo para a fase de requisitos do sistema que suportará a
organização e seus processos;
 Entender como o software se ajustará à organização.

Papéis e Artefatos
A importância da definição de papéisnão é somente para melhorar divisão
do trabalho, mas principalmente para que hajana equipe responsabilidades
definidas para cada atividade realizada, fazendo, assim,com que os
membros tenham que cumprir direitinho as suas tarefas e que respondam
por elas.
 Gerente de Projeto
 Analista de Processos de Negócio (Dentro da disciplina de
Modelagem de Negócios, esse é o papel mais importante)
 Designer de Negócio

Gerente de Projeto
Talvez seja um dos únicos papéis que estarão presentes em todos os
projetos e em todas as suas fases, independente do tamanho, natureza ou
metodologia de desenvolvimento adotada.
Inicialmente, o gerente de projeto era o indivíduo que identificava as tarefas
necessárias, as delegava aos membros da equipe e ficava pressionando
cada um para cumprir os prazos.
Hoje, essa realidade mudou. O gerente de projeto é um indivíduo
extremamente participativo: realiza parcerias com os membros da equipe,
estimula e valoriza as soluções encontradas e conduz o andamento do
projeto, protegendo a equipe de distrações e organizando cronogramas,
defende os interesses do time e realiza a comunicação com o cliente.

Analista de Processos de Negócio

Designer de Negócios

Relação com Outras Disciplinas
A disciplina Requisitos utiliza modelos de negócios como um
importante subsídio para entender os requisitos do sistema.
A disciplina Análise e Design utiliza entidades de negócios
como subsídio para identificar classes de entidade no modelo
de design.
A disciplina Ambiente desenvolve e mantém artefatos de
suporte, como o Guia de Modelagem de Negócios.

DISCIPLINA DE
REQUISITOS

O objetivo da disciplina Requisitos é descrever o que o sistema deve fazer e
permite que desenvolvedores e clientes concordem com essa descrição.
Para conseguir isso, obter, organizar e funcionalidade documento desejado
e restrições; acompanhar e documentar compromissos e decisões.
Uma visão do documento é criada, e necessidades das partes interessadas
são extraídas. Atores e casos de uso são identificados.
REQUISITOS

O QUE É UM REQUISITO?
 Condição ou capacidade que um sistema deve desempenhar
 Qualidade de software
 Funcionalidade: requisitos funcionais
 Requisitos não funcionais
 Usabilidade
 Confiabilidade
 Performance
 Suportabilidade – manutenabilidade

TIPOS DE REQUISITOS
 Serviços (features)
 Expressões de comportamento do sistema em alto nível (o quê)
 Solicitações dos stakeholders
 Requisitos do software
 Requisitos de casos de usos

Processo de levantamento de requisitos propos
to pelo RUP (José Martins, 2004)
REQUISITOS

ATIVIDADES

ARTEFATOS

ENGENHARIA DE REQUISITOS
É fundamental para o desenvolvimento de um software a compreensão dos
requisitos. Se a análise e a especificação das funções não forem definidas
adequadamente o software não atenderá as necessidades do usuário.
A Engenharia de Requisito tem como objetivo a elaboração de um
documento com as características do sistema. Este documento serve de
referência para todas as pessoas envolvidas no processo de
desenvolvimento inclusive os clientes.
Com a chegada da engenharia de requisitos, se fez necessário à
elaboração de um processo visando organizar as atividades. É o que
analisaremos nos tópicos abaixo.

Processo de Engenharia de Requisitos
O processo de Engenharia de Requisitos é um conjunto de atividades a
serem seguidas para desenvolver um documento de requisitos.
Sommerville sugere um modelo de atividades que pode descrever a maioria
dos processos de Engenharia de Requisitos.
As atividades nem sempre ocorrem sequencialmente, em geral realizam
varias repetições ou são executadas paralelamente.
 Elicitação
 Análise e Negociação
 Especificação
 Validação

Processo de Engenharia de Requisitos

eXtensible Markup Language
Elicitação dos Requisitos
O objetivo é obter conhecimentos relevantes do problema a ser resolvido. Segundo
Kotonya e Sommerville existem 4 dimensões na atividade de elicitação de requisitos:
 Entendimento do domínio da aplicação – entendes-e a área na qual o
sistema será aplicado;
 Entendimento do problema – com auxilio do sistema a ser resolvido,
entende-se os detalhes do problema especifico a ser resolvido;
 Entendimento do negócio – entende-se qual a contribuição do sistema
para que sejam atingidos os objetivos gerais da organização;
 Entendimento das necessidades e das restrições dos stakeholders –
entende-se detalhadamente: as necessidades de apoio a serem providas
pelo sistema à realização do trabalho e aos interesses de cada um dos
stakeholders; os trabalhos a serem apoiados pelo sistema e; o papel de
eventuais sistemas existentes na execução e condução dos processos de
trabalho.

eXtensible Markup Language
Análise e Negociação dos Requisitos
Depois da elicitação de requisitos todo esse conhecimento adquirido pelos
stakeholders precisa ser representado através de notações diversas. Essas
representações precisam estar sempre consistentes.
Negociação de requisitos é uma atividade extremamente complexa, ter um
entendimento global de todos os objetivos, soluções e interação entre eles é uma
tarefa muito difícil de executar. Assim existem diferentes métodos e técnicas de
negociação.
Robinson estabelece uma infraestrutura para modelar o processo de negociação:
 Perspectivas de negociação
 Processos de negociação
 Produtos da negociação

Especificação dos Requisitos
Após serem identificados e analisados os requisitos devem ser documentados para
que possam servir de base para o resto do processo.
Administrar o volume de informações que são gerados pelo processo de engenharia
de requisitos é um dos principais problemas que se enfrenta na documentação de
requisitos. Para se tornar um pouco mais fácil a administração desse documento usa-
se uma notação gráfica que diminui o tamanho do modelo.
Cada engenheiro de requisitos usa um modelo para fazer sua documentação. A seguir
são mostrados três modelos de documentos que são encontrados na literatura:
Modelo 1 – Roger S. Pressman
Modelo 2 – RUP (Rational Unified Process)
Modelo 3 – Wilson de Pádua Filho

Validação dos Requisitos
Esta atividade acontece no final da especificação de requisitos e seu
objetivo é verificar se a documentação dos requisitos esta consistente e se
contem todas as necessidades dos usuários.
A revisão é uma das técnicas usadas para validar os requisitos.
Uma das maneiras para essa tarefa é utilizar um relatório de revisão.
Um grande desafio para a validação de requisitos é mostrar que a
especificação de requisitos está correta, pois não existe uma forma para
isso.

GERENCIAMENTO DE REQUISITOS
Gerenciamento de requisitos trata-se de um modelo sistemático pra
identificar, organizar e documentar os requisitos do sistema, estabelecer e
manter acordo entre o cliente e a equipe do projeto nos requisitos variáveis
do sistema.
Para ter um gerenciamento eficiente de requisitos é preciso:
 Manter uma declaração de requisitos clara;
 Atributos aplicáveis a cada tipo de requisito e;
 Rastreabilidade para outros requisitos e outros artefatos do projeto.

GERENCIAMENTO DE REQUISITOS
Existem requisitos funcionais e não-funcionais. Exemplos:
 Funcional: o usuário deve selecionar a opção de inclusão para
cadastrar um novo aluno no banco de dados.
 Não-funcional: o sistema deve ser compatível com as plataformas
Windows e Linux.
 Não-funcional: o sistema deverá ser desenvolvido em Java.
É natural que alguns requisitos possam não ser definidos corretamente no
início do projeto, para isso serão necessárias várias revisões periódicas, a fim de
detectar erros o mais cedo possível e corrigi-los logo em seguida.

DISCIPLINA DE
ANÁLISE E
PROJETO

 Após a etapa de análise de requisitos, temos
documentos de requisitos e os casos de uso
em mãos.
 Queremos agora gerar um primeiro modelo
do sistema a partir dos casos de uso.
 Este é chamado de modelo de análise.

Requisitos Análise Projeto

 Vai proporcionar um método que permita que
criemos um modelo de classes do sistema a partir
dos casos de uso
 Trará a resposta para a pergunta:
◦ Quais classes preciso para implementar estes
casos de uso?
Atividade de Análise

Casos de Uso X Análise
casos de uso análise
Descritos na linguagem do
cliente
Descrito na linguagem dos
desenvolvedores
Visão externa do sistema Visão interna do sistema
Captura as funcionalidades do
sistema
Mostra, de modo abstrato,
como a funcionalidade pode
ser realizada
Estruturado por casos
de uso
Estruturado por classes e
pacotes

 O modelo de análise e projeto contém as
realizações de casos de uso
 Pode ser particionado em dois modelos
◦ Modelo de Analise
◦ Modelo de Projeto
Modelo de Analise e Projeto

Realização de Caso de Uso
Diagramas de Classe
Diagramas de Classe
Realização de Caso
de Uso
Caso de Uso
Diagramas de Colaboração
Diagramas de Colaboração
Diagramas de Sequência
Diagramas de Sequência
Descreve como o
caso de uso é
realizado, associando
o caso de uso com
classes e outros
elementos de projeto
 Requisitos   Analise e projeto 

MDS - Bacalá
Fluxo de Análise e Projeto
Diagrama de
Atividades

Fluxo de atividades simplificado
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados

Exemplo de arquitetura inicial
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de
Estoque
Socket

Analisar caso de uso
Para cada caso de uso
 Identificar as classes de análise
• Classes de fronteira
• Classes de controle
• Classes de entidade
Para cada classe
 Identificar responsabilidades das classes
 Identificar relacionamentos
 Identificar atributos

Projetar classes
Para cada classe
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais

Projetar Banco de Dados
 Mapear as classes persistentes em conceitos do
Banco de Dados
 Definir os tipos de dados mais adequados para o
Banco de Dados
 Normalizar se necessário

DISCIPLINA DE
IMPLEMENTAÇÃO

Disciplina de Implementação
OBJETIVOS
 Definir a organização do código em termos de subsistemas de
implementação organizados em camadas
 Implementar classes e objetos em termos de componentes (arquivos-
fonte, binários, executáveis e outros)
 Testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores individuais (ou
equipes) ao sistema executável

Visão Geral das Atividades de Implementação
Modelo de projeto
Modelo de dados
Implementação
Documento da
arquitetura
Modelo de implementação
Componentes
Plano de Integração
Documento da
arquitetura

Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Planejar Integração

 Identificar quais componentes participam da iteração (colaboram para
os casos de uso da iteração)
: Cliente
Controlador
Cliente
Maquina
Dinheiro
Banco
Leitora Cartao Cliente
Formulario
Saque
insere cartao
iniciar sessao (dados cartao)
solicita senha
solicita senha
entra senha
entra senha
new Cliente (dados cartao, senha)
v erif ica senha
solicita v alor
solicita v alor
entra v alor
entra v alor
v erif ica saldo (v alor)
solicita debito (v alor)
solicita dev olucao cartao
solicita entrega dinheiro
cartao
dinheiro

 Identificar quais pacotes participam da iteração (colaboram para os
casos de uso da iteração)
Applicação
Negócio
Middleware
Básico
*
*
*
*
*
Candidatos a Stubs
x
x

Aplicação
Comunicação
Negócio
Dados
3
Stubs
2
2
1
1
a
a b
b
c
c d
d
e
e g
g
f
f
h
h i
i j
j
 Definir os builds que serão gerados

 Avaliar resultados
◦ A ordem de integração reduz a necessidade de criação de
stubs?
◦ A ordem de integração facilita a detecção de erros?

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Estruturar Modelo de Implementação

Estruturar Modelo de Implementação
 Modelo de Implementação
◦ Modelo de projeto gerado a partir da engenharia reversa do
código fonte do sistema

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Implementar Componentes

 Check-out dos componentes
 Implementar
◦ Operações
◦ Inicialização dos atributos
◦ Estados
 Comentar o código implementado
◦ Seguindo um padrão de codificação

 Avaliar o código implementado
◦ Padrão de codificação
◦ Fatores de qualidade de OO e Java
 Compilar o código implementado
◦ Com a última versão estável dos componentes auxiliares
◦ Com a versão mais recente dos componentes implementados
 Check-in dos componentes

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Corrigir Defeitos

Corrigir Defeitos
 Check-out dos componentes
 Estabilizar a ocorrência do defeito
◦ Identificar casos de teste mínimos que causam o defeito
 Localizar o defeito no código
◦ Isolado do ambiente de produção
◦ Com ferramenta de depuração
◦ Comentando trechos do código
◦ Criando stubs
 Corrigir o defeito no código

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Realizar Testes de Unidade

Realizar Testes de Unidade
 Implementar componentes de teste
◦ Separados dos componentes a serem testados
◦ Usando ferramenta para geração dos componentes de teste
 Ex: Junit
◦ Aproveitando componentes implementados anteriormente (Check-out)
 Check-in dos componentes de teste
 Executar testes e avaliar resultados

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Revisar Código

Revisar Código
 Revisar código
◦ Com base nos seguintes documentos:
 Padrão de codificação
 Fatores de qualidade de OO e Java
◦ Sem verificar se casos de uso foram corretamente
implementados
◦ Função corretiva, mas também educativa
 Passar mudanças para o programador responsável

Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
Integrar Sistema e Subsistemas

Integrar Sistema e Subsistemas
 Check-out de todos os componentes do repositório
principal
 Integrar componentes em um build
 Notificar responsável pelos defeitos
 Criar tag (identificador) para o build
 Divulgar o build

DISCIPLINA DE
TESTE

DISCIPLINA DE
IMPLANTAÇÃO

Finalidade: Descrever as atividades que garantam que o produto de
software será disponibilizado a seus usuários finais.
Disciplina de Implantação
Esta Disciplina descreve três modos de implantação de produto:
 A instalação personalizada
 O produto em uma forma "compacta"
 Acesso ao software por meio da Internet
Em cada instância, a ênfase é testar o produto no local de desenvolvimento,
seguido de testes beta, antes de ele ser finalmente oferecido ao cliente.

Fluxo de Trabalho

Atividades

Os papéis envolvidos e os artefatos produzidos na
disciplina Implantação.

Aula de processos introdução de Software

Mais conteúdo relacionado

Semelhante a Aula de processos introdução de Software

Mais de Renan Assunção

Último

Aula de processos introdução de Software

Notas do Editor