ENGENHARIA DE SOFTWARE

A meta da engenharia é desenvolver software de boa relação custo-benefício.

O que é engenharia?
Arte de aplicar os conhecimentos científicos à invenção, aperfeiçoamento ou utilização da
técnica industrial em todas as suas determinações. (dic. Michaelis)
Engenharia de software “é uma disciplina da engenharia que se ocupa de todos os aspectos
da produção de software, desde os estágios iniciais de especificação do sistema até a
manutenção deste sistema, depois que ele entrou em operação”.

A engenharia de software abrange três elementos fundamentais:

1.Processos
2.Ferramentas/tecnologia
3.Pessoas

O PROCESSO DE SOFTWARE
É um conjunto de atividades e resultados associados que geram um produto de software. Estas
atividades são executadas por engenheiros de software.
Quais são as atividades básicas num processo de desenvolvimento de um produto qualquer?
Existem os mais variados processos de software e eles organizam estas fases básicas cada um
da sua maneira.

O QUE GERENTES PERGUNTAM?

1.Por que demora tanto tempo para que os programas sejam concluídos?
2.Por que os custos são tão elevados?
3.Por que não descobrimos todos os erros antes de entregarmos o software aos nossos clientes?
4.Por que temos dificuldade em medir o progresso enquanto o software está sendo
desenvolvido?

CARACTERÍSTICAS DO SOFTWARE
O software é desenvolvido ou projetado por engenharia, não manufaturado como um produto
industrial.
Software não se desgasta.
Software não sofre doenças, não tira férias nem recebe salário.
 A maioria dos softwares é feita sob medida em vez de ser montada a partir de componentes
existentes.

CRISE DE SOFTWARE
Problemas de software que não funcionam adequadamente, problemas de desenvolvimento,
como manter o volume crescente de atualizações e a demanda de novos softwares ou
funcionalidades.

Problemas:
Não é dedicado tempo suficiente para coleta de dados sobre o processo de desenvolvimento,
o processo deve ser medido.
Insatisfação do cliente com o sistema concluído.
Qualidade de software é suspeita!
O software existente é difícil de manter.

RESOLVENDO PROBLEMAS
Geralmente os problemas que devem ser resolvidos são complexos portanto sua resolução
necessita de análise, ou seja, uma investigação.

CONCEITOS – ANÁLISE
Análise:
1. Decomposição de um todo em suas partes constituintes.
2. Exame de cada parte de um todo, tendo em vista conhecer sua natureza, suas proporções,
suas funções, suas relações, etc.
3. A análise de sistema é usada em todos os campos onde há um trabalho de desenvolvimento
de algo (produto (software inclusive!) e serviços).
4. É o estudo do agrupamento de entes que compõem e/ou interagem para formar um sistema.
5. Este campo está intimamente relacionado com a análise de requisitos ou operações de
investigação.
6. Pode-se dizer que é: "um inquérito formal explícito realizado para ajudar alguém
(geralmente o analista de sistemas) a identificar um melhor curso de ação e, tomar uma decisão
melhor”.

“Análise” é uma palavra originário do grego, e significam: dissolver, desmontar.

 A análise é utilizada em várias disciplinas (como engenharia, psicologia, etc) para designar
procedimentos de investigação.
A análise é definida como o processo pelo qual nós dividimos o que esta sendo investigado
em partes menores que serão estudadas individualmente e/ou em conjunto conforme o caso.

A análise pode também ser definida como um conjunto de atividades que realizam a função
orgânica em conjunto de atividades maiores no projeto.
Função orgânica é o que desempenham elementos que tem estrutura e comportamento similar.
Durante o desenvolvimento de sistemas para computadores temos uma fase chamada de
análise de sistemas (análise de requisitos), nela são desenvolvidos vários diagramas e modelos
que retratam o domínio do problema que será tratado.
Talvez um dos mais importantes diagramas seja o modelo de dados ou diagrama entidade
relacionamento.
Existem um número de abordagens diferentes para a análise do sistema

O analista realiza a tarefa de decompor os problemas dos usuários em partes e representar

estes problemas usam uma linguagem previamente padronizada (geralmente diagramas),
partindo então para a construção do software (sistema).

A análise de sistemas é um conjunto de técnicas para a solução de problemas usando uma

combinação de hardware e/ou software.
A análise de sistemas geralmente decompõe as atividades manuais realizadas dentro de
empresas, as representa formalmente, utilizando diagramas, dicionarizando dados e processos,
relações, objetos, regras de negócio e propõem uma solução computadorizada, esta solução
computadorizada é o sistema que o usuário final deverá usar.

Analista de sistemas: Perito na definição e no desenvolvimento de algoritmos necessários à

solução de um problema particularmente dos algoritmos que podem ser resolvidos num
computador.

Sistema:
1.Conjunto de elementos, materiais ou ideias, entre os quais se possam encontrar ou definir
alguma relação.
2.Disposição das partes ou dos elementos de um todo, coordenados entre si, e que funcionam
como estrutura organizada.
3.Reunião de elementos naturais da mesma espécie.

O QUE É UM SISTEMA?
É uma quantidade de elementos interconectados, ordenados por uma força interna e ou
externa. O ordenamento interno do sistema se expressa no conjunto de leis de conexão ou ações
de interação entre seus elementos. Cada lei expressa determinada ordem ou tipo de nexos entre
certos fenômenos ou processos.

CONCEITOS
A Teoria Geral dos Sistemas nos diz:
1. Quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias
diferentes.
2. Quanto maior for um sistema, maior o número de seus recursos que serão destinados a
manutenção diária.
3. Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em
sistemas menores.
4. Sistemas crescem.

ETAPAS BÁSICAS DE UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

1 Análise de requisitos de software
2 Especificação de requisitos
3 Projeto do sistema
3 .1. Arquitetura de Software e seus componentes
4 Implementação (ou codificação)
4.1. Programação do sistema e banco de dados
5 Teste
5.1. Testes unitários, integração, usabilidade, etc
6 Documentação
6.1. Para administradores, gestores, usuários e desenvolvedores
7 Suporte e Treinamento de usuários
8 Manutenção
9 Desativação ou substituição
CONCEITOS BÁSICOS – PROCESSOS
Um conjunto de tarefas ordenadas constitui um processo, uma séria de etapas que envolvem
atividades, restrições e recursos para alcançar a saída desejada.

Um processo é um conjunto de procedimentos, organizados de modo que nos permita

construir produtos que satisfaçam a uma série de objetivos e padrões.

CARACTERIZAÇÃO DE UM PROCESSO
Um processo envolve um conjunto de ferramentas e técnicas, entre elas:
a) o processo deve descrever todas as suas atividades
b) o processo utiliza recursos e está sujeito a restrições dos mesmos
c) o processo pode ser composto de sub-processos
d) cada atividade do processo tem critérios de entrada e saída
e) as atividades são organizadas em sequência, com uma ordem de execução
f) todo processo tem um conjunto de diretrizes que explicam os objetivos de cada atividade
g) restrições e controles podem ser aplicadas a cada atividade.

TIME-LINE

CASCATA
Características:

Um dos primeiros modelos, proposto por Winston W. Royce, em 1970. O desenvolvimento

de um estágio deve terminar antes do próximo começar. Só quando todos os requisitos forem
enunciados é que a equipe de desenvolvimento pode iniciar suas atividades. Pode ser usado
para estimar quando falta para o término do projeto. É fácil de explicar aos clientes.
 Não reflete como o código é desenvolvido. É frequentemente utilizado na resolução de
problemas nunca antes resolvidos. Ao final de cada fase é produzido um artefado, sem detalhar
como. Trata o desenvolvimento de software como resolução de problema. Enfoque nos
documentos e artefatos.

ESPIRAL
Criado por Barry Boehm em 1988, é similar a um “risco envolvido” que forma o desenho da
espiral. É um modelo incremental e interativo.

Primero concebe as operações, depois gera requisitos, depois desenvolve e finalmente

habilita os testes, reiniciando o ciclo novamente.

PROTOTIPAÇÃO
A prototipação pode ser a base de um processo de software. Permite o desenvolvimento
rápido para esclarecer dúvidas, reduzindo os riscos e a incerteza do desenvolvimento.

O protótipo começa com um conjunto simples de requisitos, quando apresentado aos clientes,
este protótipo passa por refinamentos sucessivos, até que um protótipo final tenha sido obtido,
permitindo então a codificação final.

MODELO V
É uma variação do modelo em cascata. Proposto pelo ministério de defesa da Alemanha em
1992. A codificação é o vértice do V, a análise e projeto ficam em um lado e o testes do outro.
Durante a verificação de problemas (lado direito), caso encontrados) o lado esquerdo pode ser
revisto, permitindo a correção.

O modelo V pode ser incrementado com prototipação.

Principais desvantagens: Não aborda operações, manutenção, reparo nem descarte de

sistemas!
DESENVOLVIMENTO ORIENTADO AO REUSO
Sommervile (2003), na maioria dos projetos de software, ocorre algum reuso de software.
Isto acontece quando as pessoas envolvidas no projeto de um software conhece outros projetos
similares.
Estes softwares similares sofrem pequenas modificações e são incorporados ao novo projeto
em desenvolvimento.
A abordagem voltada para a componentização de software, também trata do reuso de código
entre projetos.
Uma categoria de sistemas que se beneficia desta forma de trabalho são “softwares de
prateleira”, pois muitos possuem funções similares, nesta categoria entram pequenas
automações comerciais.
Sua principal vantagem está na redução de software a ser produzido, também propicia a
redução do tempo de entrega. Sua desvantagem está no controle sobre a evolução do sistema,
pois partes do sistema, componentizadas estão sob controle de terceiros.

DESENVOLVIMENTO ÁGIL
1.Acceptance Test Driven Development (ATDD)
2.Agile Modeling
3.Agile Unified Process (AUP)
4.Continuous integration (CI)
5.Crystal Clear
6.Crystal Methods
7.Dynamic Systems Development Method (DSDM)
8.Extreme Programming (XP)
9.Feature Driven Development (FDD)
10. Graphical System Design (GSD)
11. Kanban
12. Lean software development
13. Scrum
14. Scrum-ban
15. Story-driven modeling
16. Test-driven development (TDD)
17. Velocity tracking
18. Software Development Rhythms
SCRUM
Scrum é um processo iterativo de desenvolvimento incremental de software.
Ele vai do desenvolvimento de produto até a entrega da aplicação.
Seu foco está em:
Ser uma estratégia de desenvolvimento flexível, do produto, onde uma equipe de
desenvolvimento funciona como uma unidade para alcançar um objetivo comum.
Os criadores (em 1986 foram Hirotaka Takeuchi e Ikujiro Nonaka) descreveram o scrum
como: “uma nova abordagem para o desenvolvimento de produtos comerciais que aumenta a
velocidade e flexibilidade, com base em estudos de caso de empresas de fabricação nas
indústrias de fotocopiadoras, automotivo e impressora”.
Eles chamaram esta abordagem de holística ou rugby, porque todo o processo é realizado por
uma equipe multifuncional em várias fases sobrepostas

KANBAN BOARD

CONSIDERAÇÕES SOBRE OS PROCESSOS

Conhecer os processos de desenvolvimento habilita o aluno a realizar uma melhor escolha de
processo para uso em projetos futuros.
A vantagem de conhecer vários processos permite inclusive evitar futuros problemas com
projetos em andamento (o principal seria a mudança da metodologia de trabalho) o que impacta
no custo e cronograma do projeto.
Também permite conhecer vantagens e desvantagens de cada um possibilitando que se possa
inclusive desenvolver um processo próprio e específico para uma empresa ou projeto de
software.

ANÁLISE DE REQUISITOS
Análise de Requisitos é... A extração dos requisitos de um cliente.
 A especificação é a tarefa de descrever precisamente o software que será construído, usando
notações formais e padronizadas.
Para alguns podem ser termos sinônimos.
A identificação dos requisitos engloba várias tarefas que podem ser conhecidas como
“engenharia de requisitos”.

O que é um Requisito?
1.É a definição documentada de uma propriedade ou comportamento que um produto ou serviço
particular deve atender.
2.Informações fundamentais para a fase de projeto de um produto ou serviço, especificando as
propriedades e funções necessárias (ou desejáveis) a serem consideradas no desenvolvimento
do projeto em questão.
3.É à definição de uma característica, atributo, habilidade ou qualidade que um sistema (ou
qualquer um de seus módulos e subrotinas) deve necessariamente prover para ser útil a seus
usuários.
Análise de requisitos é usada alternadamente com Engenharia de requisitos.

Análise de requisitos é usada alternadamente com Engenharia de requisitos...

sinônimos:
1.Levantamento de requisitos
2.Captura de requisitos
3.Especificação de requisitos
4.Análise de requerimentos


Etapas:
1.Entrevistas (Elicitação) dos requisitos: é a tarefa de comunicar-se com os usuários e clientes
para determinar quais são os requisitos de sistema.
2.Análise de requisitos: determina importância e o grau de entendimento do que foi levantado
(se o estado do requisitos é obscuro, incompleto, ambíguo, ou contraditório e resolve estes
problemas).
3.Documentação dos requisitos: os requisitos podem ser documentados de várias formas, tais
como documentos de linguagem natural, casos de uso, ou processo de especificação.

Formas de levantamento:
1.Entrevistas e Questionários: é técnica mais simples de utilizar.
2.Workshops de requisitos: promove-se a interação entre todos os elementos presentes
(Brainstorming).
3.Cenários: leva pessoas a imaginarem o comportamento de um sistema é o uso de cenários.
Através de exemplos práticos descritivos do comportamento de um sistema.
4.Protótipo: Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco
definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação
verbal não são tão facilmente identificáveis.
5.Estudo etnográfico: é a análise de componente social das tarefas desempenhadas numa dada
organização, observação pode ser acompanhada de registros áudio/vídeo.

Cliente = paga a conta do desenvolvimento do sistema

Usuário = trabalha com o sistema

Um problema deve ser dividido em partes

Os requisitos devem ser entendidos
Podem ser usadas abstrações para documentar os requisitos
Deve-se ter em mente as fronteiras do sistema

O que é SDLC?
systems development life cycle
Ciclo de vida do desenvolvimento de sistemas
IRISE
BLUEPRINT
RALLY EXPRESS
SPIRAPLAN
AXIOM
CASESPEC
CALIBER
OSRMT
ANIMBLE

ESPECIFICAÇÃO – CONCEITOS
Especificar:
1.Descrição, determinação circunstanciada.
2.Definição das características às quais deve responder uma instalação, uma construção, um
material, uma confecção, um produto etc.
3.Enumeração.

Especificação de software:
Uma especificação de programa é a definição do que se espera que um programa de
computador faça. Ela pode ser informal, neste caso ela pode ser considerada como um blueprint
ou manual de usuário do ponto de vista do desenvolvedor, ou formal, no caso de ela ser definida
principalmente em termos matemáticos ou programáticos.
“especificação de software” em inglês é conhecida pela sigla: SRS - Software Requirements
Specification.

O SRS (Software Requirements Specification) é basicamente a compreensão de uma

organização e cliente (por escrito) de um requisitos do sistema para este potencial cliente e
realizado em determinado ponto no tempo (geralmente) antes de qualquer projeto real ou
trabalho de desenvolvimento tenha início.
É uma apólice de seguro de duas vias, que assegura que tanto ao cliente como para a
organização entender as necessidades de ambas as partes.

O documento SRS afirma em linguagem precisa e explícita as funções e capacidades de um

sistema de software (isto é, uma aplicação de software, um site de comércio eletrônico, etc)
deve fornecer, bem como estabelece quaisquer restrições exigidas pelo qual o sistema deve
respeitar.
Dica: ver requisitos funcionais e não funcionais!
O SRS é muitas vezes referida como o documento de "pai", porque todos os documentos de
gerenciamento de projetos subsequentes, tais como especificações de projeto, instruções de
trabalho, especificações de arquitetura de software, testes e planos de validação, e os planos de
documentação, estão relacionados a ele.

É importante notar que uma SRS contém os requisitos funcionais e não-funcionais apenas!
A SRS não oferece:
sugestões de design
as possíveis soluções para questões de tecnologia ou de negócios

Se a especificação for bem escrita ela deverá atingir 4 objetivos:

1.Fornece um feedback ao cliente. O SRS é a garantia do cliente de que a equipe de
desenvolvimento compreende as questões ou problemas a serem resolvidos e o comportamento
software necessário para lidar com esses problemas. Portanto, a SRS deve ser escrito em
linguagem natural (simples português),
Poderá também incluir: gráficos, tabelas, diagramas de fluxo de dados, tabelas de decisão,
etc.
2.Decompõe-se o problema em partes.
O simples ato de escrever os requisitos do software em um formato bem projetado resulta em
organização de informações, coisas, fronteiras em torno do problema, solidifica ideias e ajuda
a quebrar o problema em suas partes componentes de uma forma ordenada.
3.Serve como documento pai de documentos posteriores.
Portanto, a SRS deve conter detalhes suficientes nos requisitos funcionais de sistema para que
uma solução de projeto possam ser elaboradas.
4.Ele serve como documento para testes e estratégias de validação que serão aplicadas aos
requisitos para a verificação.... Durante ou no final do projeto.
EXEMPLO DE UMA SRS

ANÁLISE E ESPECIFICAÇÃO

Técnicas para realizar as atividades acima:

1.Entrevistas e Questionários
2.Workshops de requisitos
3.Cenários
4.Protótipo

COMO ESCREVER REQUISITOS?

1.Utilizando uma descrição estática (listas de componentes do futuro sistema, utilizando
diagramas de classes, expressando condições usando linguagem natural, etc)
2. Utilizando uma descrição dinâmica (utilizando diagramas de transição, descrevendo
eventos que mudam o comportamento do sistema, tabelas de eventos, diagramas de atividade e
sequência, etc)
3. Prototipação
1.Abordagem evolutiva: aproveita o modelo
2.Abordagem descartável: na fase de codificação é criado um sistema novo que será utilizado
pelo cliente

NÍVEL DE ESPECIFICAÇÃO
A diferença de experiência entre analistas resulta em especificações muito diferentes.
Técnicas de escrita diferentes.
O nível de detalhamento não pode (não se recomenda) mudar em módulos diferentes de um
mesmo sistema.
Os requisitos que geralmente são mal especificados ou em alguns casos são ignorados são:
ambiente de operação
ambiente de treinamento
administração do sistema em produção
tolerância a falhas

ARQUITETURA DE SOFTWARE
1.Decomposição de modularidade:
É a separação dos elementos constitutivos de um corpo.
Desagregação de seus componentes e estruturas menores.
Transformação do sistema em pequenas partes de forma que possam ser tratadas
separadamente, porém continuam tendo suas funcionalidades mantidas para que o conjunto
possa operar.
Também chamada de modularização:
O sistema ou software é divido em partes distintas.

TIPOS DE DECOMPOSIÇÃO
1.Modular: essa abordagem tem como base a atribuição de funções aos componentes. O
projetista começa com uma descrição de alto nível das funções que serão implementadas e cria
explicações de nível inferior sobre como cada componente será organizado.
2.Orientada a dados: tem como base as estruturas de dados.
3.Orientada a eventos: trata os eventos com os quais os sistemas deve lidar e utiliza as
informações sobre como o sistema deve lidar com os eventos que modificam seu estado.
4.Projeto OO: o projeto identifica classes de objetos e o relacionamento entre elas. Em um nível
superior, é descrito cada tipo de objeto. Em níveis inferiores atributos e ações.