DESENVOLVIMENTO DE SOFTWARE

Um detalhe que foge ao entendimento comum: um programa de

computador apenas aquilo que est no meio virtual; j um software
compreende o programa de computador e a sua documentao.
-O que Engenharia de Software?
A Engenharia de Software abrange um conjunto de prticas e
ferramentas que possibilitam aos profissionais desenvolverem software de
qualidade.
Os mtodos (prticas) da engenharia de software baseiam-se em um
conjunto de princpios bsicos que norteiam o desenvolvimento de
software.
Nesse contexto encontra-se a Engenharia de Requisitos, que iremos
estudar.

1- ENGENHARIA DE REQUISITOS
-PROBLEMAS DO DESENVOLVIMENTO DE
SOFTWARE
A parte mais difcil de construir um software decidir precisamente o que
deve ser feito.
Nenhuma outra parte do trabalho conceitual to difcil do que estabelecer
os requisitos detalhados, incluindo todas as interfaces com pessoas,
equipamentos e outros sistemas.
Nenhuma parte do trabalho influencia tanto o sistema resultante se feita
incorretamente.
Nenhuma parte mais difcil de retificar posteriormente.
-REQUISITOS
Requisitos so uma especificao do que deve ser implementado. Eles
constituem descries de como o sistema deve ser comportar, ou uma
propriedade ou atributo do sistema. Podem caracterizar uma restrio
no processo de desenvolvimento do sistema.
Classificao dos requisitos quanto natureza:
Requisitos funcionais
Requisitos
- de produto, organizacionais e externos
Requisitos de domnio

no-funcionais

Classificao dos requisitos quanto visibilidade

( a linguagem dos requisitos)
Requisitos de usurio
Requisitos de sistema
Requisitos de desenho (ou especificao de projetos de software)
Classificao dos requisitos quanto qualidade
Requisitos normais
Requisitos esperados

Requisitos fascinantes
Classificao dos requisitos quanto evoluo
Requisitos permanentes
Requisitos volteis
Classificao FURPS+

ele parte do Rational Unified Process (RUP)

mnemnico- FURPS= Funcionalidade, Usuabilidade

(performance),
Confiabilidade,
Performace,
Suportabilidade(compatibilidade).

O + do acrnimo engloba outros requisitos no-funcionais

que devem ser lembrados:
Requisitos de design/ desenho (restringe o desining);
Requisitos de implementao (Um requisito de implementao especifica
ou restringe o cdigo ou a construo de um sistema);
Requisitos de interface (relacionado comunicao do sistema em pauta
com outros sistemas.) ;
Requisitos fsicos (especifica uma limitao fsica pelo hardware
Utilizado).

PS. Tudo aquilo q no diz respeito funcionalidade, na

classificao FURPS+, se aproxima de maneira inevitvel dos
requisitos no funcionais.
-STAKEHOLDERS
-ETAPAS DA ENGENHARIA DE REQUISITOS
Engenharia de requisitos um conjunto de tarefas e tcnicas que pretende
mapear os requisitos de um sistema da melhor forma possvel. A engenharia
de requisitos procura fornecer o mecanismo apropriado para entender aquilo
que o cliente deseja, analisando as necessidades, avaliando a viabilidade,
negociando uma soluo razovel, especificando a soluo sem
ambiguidades, validando a especificao a gerenciando as necessidades
medida que so transformadas em um sistema operacional.
Seu objetivo criar e manter um documento de requisitos de sistema.
-PRIMEIRA ABORDAGEM DA ENGENHARIA DE REQUISITOS
(SOMMERVILLE)
Estudo de Viabilidade: Utilidade para a empresa;
Elicitao e Analise: Obteno dos requisitos;

Especificao: Converso destes requisitos em um formato padro;

Validao: Alinhamento entre os requisitos e as necessidades do cliente;

Aqui gera-se um documento compreensvel pelo usurio q

deve servir como base contratual.
Gerenciamento de Requisitos: Acompanhar os requisitos ao longo do
processo de desenvolvimento do software.

Matrizes de rastreabilidade so os principais artefatos

produzidos na fase de gerncia de requisitos. Elas relacionam
os requisitos identificados a um ou mais aspectos do sistema
ou do seu ambiente, de modo que elas possam ser procuradas
rapidamente para entender como uma modificao em um
requisito vai afetar diferentes aspectos do sistema.
-SEGUNDA ABORDAGEM DA ENGENHARIA DE REQUISITOS
(PRESSMAN)
Concepo: Concepo inicial do software. O objetivo desta etapa
entender o problema, quais os envolvidos, a natureza da soluo e iniciar o
processo de comunicao entre clientes e colaboradores.
Levantamento (elicitao)
Elaborao: Refinamento das informaes obtidas na etapa anterior, com
a incluso de modelagens de cenrios de interao do usurio com o sistema
e modelagem das classes envolvidas, bem como a relao entre elas.
Negociao: Aps a etapa de elaborao, muitos requisitos no estaro de
acordo com a disponibilidade de recursos disponveis, ou sero conflitantes
entre si. Nesse ponto os requisitos so avaliados junto ao cliente e podem
ser excludos, combinados ou ainda serem acrescentados novos requisitos.

Do levantamento anlise equivale elicitao de

sommerville.
Especificao
Validao
Gesto de Requisitos

Pressman preconiza a utilizao de tabelas de rastreamento,

para
facilitar
a
gesto
de
requisitos:
Tabela de rastreamento de caractersticas. Mostra como os
requisitos se relacionam a caractersticas importantes do
sistema/produto
observveis
pelo
cliente.
Tabela de rastreamento de fontes. Identifica a fonte de cada
requisito.
Tabela de rastreamento de dependncia. Indica como os
requisitos
esto
relacionados
uns
aos
outros.
Tabela de rastreamento de subsistemas. Caracteriza os
requisitos pelo(s) subsistema(s) que eles governam.
Tabela de rastreamento de interface. Mostra como os
requisitos se relacionam com as interfaces internas e externas
do sistema.

COMPARAO ENTRE AS PRINCIPAIS ABORDAGENS DE

ENGENHARIA DE REQUISITOS
SOMMERVILLE
PRESSMAN
Estudo de Viabilidade
Concepo
Elicitao e Anlise
Levantamento
-Obteno
-Classificao e Organizao
-Priorizao e Negociao
-Documentao de Requisitos

Especificao
Validao
Gesto

Elaborao
Negociao
Especificao
Validao
Gesto

-TCNICAS DE ELICITAO DE REQUISITOS

Elicitar requisitos extrair do stakeholder o q ele qr q o software faa.

Casos de Uso
Cenrios, de maneira sucinta, a contagem de uma historinhaque simula
o que seria a interao de um usurio no sistema a ser desenvolvido, com
um determinado propsito.

JAD (Joint Application Design)

uma tcnica de levantamento interativo; So feitas reunies
participativas, chamadas de sesses, envolvendo representantes de todas as
reas relacionadas com os assuntos em discusso.
As regras da sesso:
-Todos os participantes so iguais
-Apenas uma pessoa fala de cada vez
-Todas as opinies so vlidas
-Hora para comear, interromper e terminar
-Celular desligado.( no devem acontecer interrupes externas.)
-Recursos visuais.( p/ tornar mais palpvel.)

orientado a objetos, utilizando as informaes de servio que esto

encapsuladas nos pontos de vista.

Pontos de vista de interao: representam pessoas ou outros

sistemas que interagem diretamente com o sistema.

Pontos de vista indiretos: representam os stakeholders que

no usam o sistema diretamente, mas que influenciam os
requisitos de alguma forma.

Pontos de vista de domnio: representam caractersticas e

restries de domnio que influenciam os requisitos de
sistema.

VORD (View-Oriented requirements definition) /

Pontos de Vista
Os diferentes pontos de vista a respeito de um problema vem o
problema de modos diferentes. Contudo, suas perspectivas no so
inteiramente independentes, mas em geral apresentam alguma duplicidade,
de modo que apresentam requisitos comuns.
A primeira etapa da anlise de ponto de vista identificar os possveis
pontos de vista; A segunda etapa a estruturao de pontos de vista; A etapa
de documentao do ponto de vista tem por objetivo refinar a descrio dos
pontos de vista e servios identificados; O mapeamento de sistema
conforme ponto de vista envolve identificar objetos em um projeto

Entrevistas, reunies, brainstorming

Elas podem ser fechadas (orientadas por um formulrio) ou abertas, por
meio de uma conversa natural.

Prototipagem

Etnografia
A etnografia uma tcnica de observao que pode ser utilizada para
compreender os requisitos sociais e organizacionais. Nesta tcnica, o
analista se insere no ambiente de trabalho em que o sistema ser utilizado.
-TCNICAS DE VALIDAO DE REQUISITOS
Serve para confirmar se o q vc tem realmente aquilo q o cliente deseja;

Revises de Requisitos
Revises envolvem um grupo de pessoas lendo e analisando a
documentao de requisitos procura de possveis problemas.

Prototipagem

Gerao de casos de teste

Nesta tcnica, cada requisito funcional no documento de requisitos
deve ser analisado e um teste deve ser definido que possa
objetivamente averiguar se o sistema satisfaz o requisito. O objetivo
dos casos de teste propostos para requisitos validar o requisito, e
no o sistema.

2- ANLISE, PROJETO E
IMPLEMENTAO DE SOFTWARE
O levantamento de requisitos, a anlise de requisitos e o projeto do software
no so fases isoladas entre si. Ao elaborar diagramas e confeccionar
documentos para buscar a melhor compreenso e entendimento dos
requisitos de um sistema, j comea ali a fase de anlise de requisitos. Tal
imiscuidade entre fases tambm ocorrer entre a anlise e o projeto.

-ANLISE
A fase de anlise de requisitos, no contexto do desenvolvimento de um
sistema, aquela na qual so construdos modelos para representar o
sistema a ser construdo.
Esta fase tem como caracterstica no levar com conta o ambiente
tecnolgico a ser utilizado. Nesta atividade, o foco de interesse tentar
construir uma estratgia de soluo sem se preocupar com a maneira como
essa estratgia ser realizada. Em resumo, a prioridade saber o que o
sistema proposto deve fazer, para, posteriormente (no projeto), definir como
o sistema ir faz-lo.
A modelagem de requisitos possui duas vises clssicas: a anlise
estruturada e a anlise orientada a objetos.
A anlise estruturada considera os dados e os processos que
transformam os dados em entidades separadas. Esta tcnica descreve o
fluxo de informao e transformaes que so aplicadas medida que os
dados se movimentam da entrada para a sada. O diagrama que melhor
ilustra a anlise estruturada o
Diagrama de Fluxo de Dados (DFD).
A anlise orientada a objetos, por sua vez, lana mo da abstrao -Abstrao uma operao intelectual que consiste em isolar, por exemplo
num conceito, um elemento excluso de outros, do qual ento se faz
abstrao--para representar coisas do mundo real, sob a forma de objetos.
Os objetos podem ser uma entidade externa, uma coisa, uma ocorrncia, um
evento, uma unidade organizacional, um local, enfim, qualquer elemento
que possa ser representado por um conjunto de atributos.
-PRINCIPAIS DIAGRAMAS DA FASE DE ANLISE
Modelos baseados em cenrios
Modelos de Fluxo seu principal diagrama o Diagrama de Fluxo de
Dados, ou DFD.
Modelos de Comportamento Os modelos comportamentais indicam
como o software ir responder a estmulos ou eventos externos. Os
diagramas de estado e de sequncia representam este tipo de modelo.
Modelos de classe A modelagem baseada em classes representa os
objetos que o sistema ir manipular, as operaes (tambm denominada
mtodos ou servios) que sero aplicados aos objetos para efetuar a
manipulao, alguns relacionamentos entre os objetos e as colaboraes que
ocorrem entre as classes definidas.
Os elementos de um modelo baseado em classes so: classes e objetos,
atributos, operaes, modelos CRC (classe-responsabilidade-colaborador),
diagramas de colaborao e pacotes.
-PROJETO
O foco principal da anlise so os requisitos. Na fase de projeto, determinase o como o sistema funcionar, para atender esses requisitos. Os modelos
de requisitos, apresentados por elementos baseados em cenrios, baseados
em classes, orientado a fluxos e comportamentais, alimentam a tarefa de
projeto.
Cabe destacar alguns conceitos que devem ser ponderados quando da
elaborao de um projeto:

Abstrao: medida que o nvel de abstrao migra de um nvel mais

alto para um nvel mais baixo, a soluo deixa de ser expressa na linguagem
do domnio do problema para ser expressa em uma terminologia tcnica.
Arquitetura
Padres: Os padres de projeto so solues comprovadamente eficazes
que podem ser aproveitados em projetos de problemtica recorrente.
Separao por interesses (por afinidades): Esse conceito afirma que
qualquer problema complexo pode ser tratado mais facilmente se
decomposto em trechos a serem resolvidos e ou otimizados
independentemente.
Modularidade: Dividir um software em poucos mdulos o torna fcil de
integrar, mas difcil de desenvolver e manutenir. Dividir demais o torna
difcil de integrar, embora o custo do mdulo seja baixo. O desafio do
projeto modularizar o problema da melhor forma possvel, minimizando
custos.
Encapsulamento de informaes: O princpio do encapsulamento diz que
os mdulos devem ser capazes de ocultar suas caractersticas uns dos outros,
disponibilizando apenas os itens que interessam aos outros mdulos.
Independncia funcional: A independncia funcional atingida
desenvolvendo-se mdulos com funo nica e que pouco interagem com
outros mdulos. medida qualitativamente pela coeso e pelo
acoplamento. Um mdulo coeso realiza poucas tarefas, interagindo o
mnimo necessrio com outros mdulos. Quanto ao acoplamento,
desejvel que ele seja fraco, ou seja, que cada mdulo se comunique o
mnimo possvel com os demais.
Refinamento: O refinamento gradual uma estratgia top-down. Um
programa desenvolvido refinando-se nveis procedurais sucessivamente.
Refatorao: Tcnica de reorganizao que simplifica o projeto ou cdigo,
sem mudar sua funo ou comportamento. Em projetos de refabricao de
software, deve-se examinar o projeto antigo, eliminar redundncias, corrigir
algoritmos eficientes ou desnecessrios.
Usando a notao, princpios e mtodos adequados, o projeto produz um
projeto de dados/classes, um projeto de arquitetura, um projeto de
interfaces e um projeto de componentes:
Projeto de dados/classes O projeto de dados/classes transforma os
modelos de classes em realizaes de classes de projeto e nas estruturas de
dados dos requisitos necessrios para implementar o software.
Projeto de arquitetura O projeto arquitetural define os
relacionamentos entre os principais elementos estruturais do software, os
estilos arquiteturais e os padres de projeto que podem ser usados para
satisfazer os requisitos definidos para o sistema e as restries que o afetam.
Diagramas de implantao podem mostrar os componentes fsicos de um
sistema, assim como diagramas de componentes pode mostrar os
principais componentes de um software.
Projeto de componentes O projeto de componentes destrincha
elementos estruturais da arquitetura, em uma descrio procedural dos
componentes de software.
Projeto de interface de usurio
Conjunto de desenhos detalhados que representa fluxos de informao que
entram em saem do sistema, como o sistema de comunica com sistemas

externos e com as pessoas que o utilizam. Devem ser buscadas algumas

caractersticas como: Familiaridade, Consistncia, Surpresa mnima,
Deixar o usurio no comando, Reduzir a memria do usurio.

3-IMPLEMENTAO, TESTES,
IMPLANTAO E MANUTENO
-IMPLEMENTAO
Na implementao, o sistema codificado, ou seja, ocorre a traduo da
descrio computacional obtida na fase de projeto em cdigo executvel,
mediante o uso de uma ou mais linguagens de programao.
Ao codificar um software, um programador poder escrever cdigo novo,
ou reaproveitar cdigo j existente. Esse reaproveitamento de cdigo
chamado de reuso de software.
Por fim, interessante destacar que a maioria das bibliografias prev que o
teste de unidade acontece na etapa da implementao. O teste de unidade
o teste pontual, realizado pelo programador, que verifica que aquele
componente ou mdulo que ele desenvolveu realmente faz o que deveria
fazer, atendendo s especificaes do projeto.
-TESTES
Teste de software uma atividade realizada para descobrir erros que foram
produzidos inadvertidamente no momento em que o software foi projetado
e construdo. Pode ser planejado antecipadamente e conduzido
sistematicamente. Ainda, podem ser testes de baixo nvel, no qual so
verificados se pequenos segmentos de cdigo-fonte foram corretamente
implementados, bem como testes de alto nvel, que validam as principais
funes do sistema com base nos requisitos do cliente.
Estratgias de teste de software
As estratgias de teste de software fornecem um roteiro que descreve os
passos a serem executados como parte do teste.

-Teste de validao a validao de software conseguida por meio de

uma srie de testes que demonstram conformidade com os requisitos.
O teste alfa conduzido na instalao do desenvolvedor por um grupo
representativo de usurios finais. Nele, o desenvolvedor monitora os
usurios, registrando os erros e os problemas de uso.
O teste beta conduzido nas instalaes dos usurios finais. Via de regra,
o desenvolvedor no est presente, e os erros e problemas encontrados so
reportados pelos usurios.
-Teste de sistema o teste de sistema extrapola os limites da engenharia
de software. Uma vez validado, o software dever ser combinado com
outros elementos dos sistemas (como hardware, pessoas, base de dados).
Ele verifica se todos os elementos se combinam corretamente e se a
funo/desempenho global do sistema conseguida. Podem ser:
Teste de recuperao: fora o sistema a falhar de vrias formas e
verifica se a recuperao executada corretamente;
Teste de segurana: verifica se os mecanismos de proteo incorporados
ao sistema protegem contra acesso indevido;
Teste de esforo: coloca o programa em condies anormais. At onde
podemos forar o sistema at que ele falhe?
Teste de desempenho: testar o desempenho, em tempo de execuo, do
software em um contexto de sistema integrado. Pode ser feito em conjunto
com testes de esforo;
Teste de disponibilizao: exercitar o software em cada ambiente no
qual ele deve operar, como em vrios sistemas operacionais, vrios
navegadores web, ou vrias plataformas (PC, smartphone...).
Depurao Quando um erro encontrado, o cdigo dever ser
futucado para encontrar o pedao de cdigo que est escrito de maneira
incorreta, para ento ser corrigido. A esta etapa dada o nome de
depurao.
Tcnicas de teste de software

**Verificao se refere ao conjunto de atividades que garante que o

software implementa corretamente uma funo especfica (estamos
construindo o produto corretamente?), enquanto a Validao se certifica
que o software construdo corresponde aos requisitos do cliente.
O teste proporciona o ltimo elemento a partir do qual a qualidade pode ser
estimada, e, mais pragmaticamente, os erros podem ser descobertos. a
confirmao da qualidade. Se a qualidade no estiver l antes do teste, no
estar l aps a realizao dele.
Quanto responsabilidade pela execuo dos testes, cabe aos prprios
desenvolvedores a realizao dos testes de unidade (grupo independente de
teste realiza testes mais complexos)
-Teste de unidade se concentra em cada unidade: componente, classe ou
mdulo.
-testes de integrao- Erros associados s interfaces/comunicao entre os
mdulos; no confundir com interface com o usurio.

So atributos desejveis em um teste:

Alta probabilidade de encontrar erros;
No ser redundante;
O melhor de uma categoria (o mais completo de um grupo similar de
testes);e
Nem muito simples, nem muito complexo.
Vejamos algumas tcnicas de teste:
Caixa-Branca - Tambm chamada de teste estrutural ou orientado lgica,
a tcnica de caixa-branca avalia o comportamento interno do componente
de software.
A tcnica de teste de caixa-branca recomendada para as fases de teste de
unidade e teste de integrao, cuja responsabilidade principal fica a cargo
dos desenvolvedores do software, que por sua vez conhecem bem o cdigo
fonte produzido.
Caixa-Preta - Tambm chamada de teste funcional, teste comportamental,
orientado a dado ou orientado a entrada e sada, a tcnica de caixa-preta

avalia o comportamento externo do componente de software, sem se

considerar o comportamento interno do mesmo.
A aplicao combinada de outra tcnica tcnica de particionamento de
equivalncia (ou uso de classes de equivalncia) permite avaliar se a
quantidade de casos de teste produzida coerente.
Uma outra variao a Anlise do Valor Limite na qual so testados
valores nas fronteiras de um domnio.
-IMPLANTAO
Na implantao, o sistema empacotado, distribudo e instalado no
ambiente do usurio. Os manuais do sistema so escritos, os arquivos so
carregados, os dados so importados para o sistema, e os usurios so
treinados para utilizar o sistema corretamente. Dependendo da situao,
pode ocorrer tambm a migrao de sistemas de do software e de dados
preexistentes.
-MANUTENO
A manuteno atividade sucednea e imediata entrega do software.
No existe software pronto; todo software sempre pode ser aperfeioado
e melhorado.
interessante observar tambm que esta fase pode se tornar especialmente
complicada, em virtude de alguns motivos:
Pessoal
Responsabilidade contratual
Idade e estrutura do programa
Como consequncia dos fatores acima, compreensvel que a fase de
manuteno seja de baixa produtividade e alto custo. No raro, programas
cuja manuteno torna-se invivel so descartados por software mais
moderno.
-TIPOS DE MANUTENO
Adaptativa - finalidade adequao do software ao seu ambiente e no a
correo de um defeito, ou o acrscimo de uma nova funcionalidade.
Corretiva - serve para corrigir falhas.
Evolutiva (perfectiva): so alteraes que visam agregar novas
funcionalidades e melhorias para os usurios que as solicitaram.
Preventiva: serve para melhorar a manutenibilidade ou confiabilidade
futuras, e fornecer uma base melhor para evoluo. Como, por exemplo, a
refatorao de trechos de cdigo confusos, para facilitar o entendimento
do cdigo pela equipe de manuteno.
Reengenharia
Para evoluir um sistema, muitas vezes necessrio compreender o
programa a ser mudado, para depois implementar as mudanas. Contudo,
no raro que os sistemas legados (muito antigos) no suportem mais as
manutenes clssicas, em virtude de uma estrutura concebida em outra
poca, com outras finalidades.
Para contornar esse bice, as empresas podem optar por fazer a
reengenharia desses sistemas, para aprimorar sua estrutura e facilidade de
compreenso. Na reengenharia, no se modifica as funcionalidades do

software. Lembra um pouco o conceito de refatorao, mas aplicada ao

sistema como um todo.
As atividades do processo de reengenharia so:
1) Converso de cdigo-fonte
2) Engenharia reversa: atividade-chave.
3) Aprimoramento da estrutura do programa: o programa pode ser
modificado para facilitar a leitura e compreenso (sem mudar suas
funcionalidades);
4) Modularizao do programa: partes relacionadas do programa so
agrupadas, e, quando apropriado, as redundncias so removidas.
5) Reengenharia de dados: os dados processados so alterados para
refletir as mudanas do programa. Afinal, se o programa, ao ser
aperfeioado, passar a trabalhar com dados e tabelas diferentes, os dados
precisam ser modificados para acompanhar essas mudanas.