Release Processo Desenvolvimento de Software

Prévia do material em texto

Aula 01
Sistema -> É um conjunto de partes, que mesmo independentes entre si, e com cada 
qual com seu objetivo, todos pedem para um objetivo comum.
Informação - > Existe a diferença entre Dados(Que são os fatos isolados) e a 
informação, que são esses dados processados, o qual trazem valores agregados 
após este processamento.
Sistema de Informação -> É um conjunto de elementos inter-relacionados que 
coletam dados, manipulam estes dados(processam) e distribui estes dados 
processados(informação).
Elementos do Sistema de Informação
- Hardware (Componentes físicos - Desgastes)
- Software (Componentes lógicos)
- Banco de dados (Armazenamento)
- Telecomunicações (Rede, internet)
- Pessoas (Mais importante para tudo isso)
- Procedimentos e processos (organização)
Problemas que podem afetar um Sistema de Informação:
- Pessoas que não receberam qualificação para usabilidade do sistema
- Processo de negócios inadequados ao qual o sistema está inserido
- Deficiência do próprio sistema, como exemplo má qualidade de hardware, tecnologia 
adota inadequada, a linguagem que não era eficiente e até mesmo o software mal 
elaborado e construído.
Software:
É a porção lógica de um sistema de informação, que comanda a operação do 
computador.
Tipo de Software e sua natureza:
! -Software de Sistema: Controlam as operações básicas do computador 
! (hardware), como ! exemplo: Bios, Sistema Operacional, Linguagem de 
! Programação..
! - Software Aplicativo: Sãos as interfaces (comunicação e usabilidade) criada pra 
! ser diretamente usada pelo usuário.
Software hoje e sua administração:
- Grande e complexos, os software hoje exigem organização em todos o seu processo.
- Demandam rápidas mudanças para acompanhar a velocidade da comunicação e 
informação que circulam no mundo.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Software e sua importância:
É ele o responsável direto por trazer o maior bem pra sociedade moderna, que é a 
INFORMAÇÃO.
- Toda a melhoria feita nos últimos 50 anos em hardware, redes e banco de dados, 
aumentou a capacidade de processar as informações e diminuíram os custos do 
sistema, porém, o software não acompanhou essa evolução.
A diferença entre o desenvolvimento e o sucesso do Hardware para o Software:
HARDWARE SOFTWARE
Fabricado Manufaturado
Falhas Início e Fim Falhas ao ser alterado
Substitui peças Tem que ser alterado
Montagem: Componentes padrões Desenvolvido: Difícil padronizar para 
re-uso
- O desenvolvimento do Software depende muito do componente humano.
- Existe pouca automação no desenvolvimento 
- Visão de projeto inadequado
! ! * Histórico: Gestor de TI sem formação Administrativa.
! ! * Gestão: Planejamento, organização e controle de prazos e custos 
! ! ineficientes
!
! - Pressão dos usuários/clientes para rapidez na entrega do software
! ! * Daí vem os problemas de Prazos, custos e comunicação.
Ciclo de Vida de um Software:
O ciclo de vida de um software são todas as etapas do desenvolvimento
1 - Começo - > Percepção de necessidades
2 - Desenvolvimento -> Transformação dos conjuntos de itens a ser entregue ao usuário
3 - Operação -> Neste momento o software está em uso e está sujeito a manutenção
4 - Fim -> É retirado de operação ao final da vida útil, ou seja, enquanto trouxe valores 
para a organização.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Os Processos de Desenvolvimento
 
- Todo o processo de desenvolvimento precisa ter organização e normas determinadas, 
sistemáticas e não improvisadas. 
- As tarefas geram as atividades e as atividades compõem o processo como um todo.
As atividades do Processo:
- Concepção - A ideia do software
- Requisitos - O que o cliente pensa sobre o software
- Análise - Estudo pra saber a viabilidade do projeto
- Projeto - Saber quais tecnologia deve se usar
- Codificação - Programação do software
- Teste - Saber se está de acordo com o planejado
- Homologação - Documentar e efetivar o processo até aqui feito
- Implantação - A atuação operacional do software
- Manutenção - Que são as mudanças que podem acontecer durante a vida do software
A organização das fases do processo, estabelecendo:
- Quais são elas?
- Finalidade de cada uma das fases?
- Ordem e ligação entre elas?
- Funcionamento do Processo
- Documentação e modelos de cada fase
Conceitos Fundamentais do Processo:
Escopo -> É a abrangência 
! - O que será considerado para o desenvolvimento
! - Quanto maior for o escopo, maior será a complexidade e dificuldade de gerenciar 
! o desenvolvimento.
Requisitos = Necessidade do usuário
! -Compreender as funcionalidades que o sistema deve possuir pela visão do cliente
! - Problemas com erros de requisitos custam mais caros de resolverem
! - Quanto mais tempo passa, pior fica.. Então o foco tem que ser total aos requisitos 
! do sistema.
Fundamental -> Definir os requisitos que farão o parte do escopo.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Engenharia de Requisitos:
Engenharia 
! - Técnica de levantamento de requisitos
! - Documentação
! - Análise de Requisitos
Problema - Levantamento e documentação de Requisitos
! - Boa documentação - Boas chances de atender aos requisitos
- Boa especificação de requisitos - Fundamental para todo o processo
Gestão dos Requisitos:
Problemas: Instabilidade nos Requisitos
- Novos requisitos e alterações de requisitos com o desenvolvimento já adiantado.
- Alto custo, re-trabalho, perda de trabalho feito. É quase o mesmo que alterar uma 
planta estrutural de uma casa, após o início da construção.
- A boa engenharia de requisitos tende a reduzir a instabilidade, obtendo os 
requisitos no momento oportuno.
Prazos e Custos:
- Requisitos -> Prazos e Custos
- A quantidade e complexidade dos requisitos mandam na relação de causa e 
efeito sobre os prazos e custos e isso pode gerar insatisfação do cliente.
- A grande questão -> No início do processo só temos requisitos..
- Então é difícil medir os programas necessários com base em requisitos
- Após o projeto detalhado se conhece o melhor os detalhes. Porém, os usuários 
não sabem e nem querem esperar.
- É preciso -> Perceber que...
- Planejamento e controle de projetos são essenciais
! ! - Análise dos riscos(Probabilidade de sua ocorrência e ações corretivas, 
! ! caso seja preciso acontecer)
! ! - Acompanhamento de todo o processo do projeto e isso inclui a ! ! 
! ! renegociação de prazos e custos
! - Garantir a qualidade do processo
! ! - Garantir = Está em pleno acordo com os requisitos
! ! - Qualidade do produto é influenciada pela qualidade do processo
! ! - Quanto antes um problema for identificado e resolvido, será melhor pelo 
! ! fatos dos custos.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
AULA 02
Estudo de Viabilidade - A Concepção do Software:
- Chamada de fase semente, necessidade do usuário ou cliente, nasce a ideia.
- O que é o sistema? Precisamos a partir da necessidade e as ideias, precisamos saber o 
que o sistema é..
- Ele é viável? Vale a pena ? Se for, entramos na fase de Estudo ou Análise de 
Viabilidade.
- Os benefícios vai superar os custos?
- Deve ser considerar a empresa e o tipo de negócio que a empresa trabalha.
Entrada:
1 - Quais são as necessidades levantadas para que se tenha o software.
2 - Descrever o que é, os objetivos, gerais e tudo que se quer sobre o software.
3 - Saber como e onde ele vai se inserir dentro da empresa.
Saída:
1 - Ocorrendo a Análise de Viabilidade e a saída vai dizer, se é viável de forma técnica, 
operacional e financeira.
! a) O Software contribuiu para a organização? Viabilidade Operacional.
! b) O Software pode ser implementado com TI atual? Viabilidade Técnica.
! c) Restrições de custos serão atendidas? Viabilidade Econômica.
! d) Restrições de prazos serão atendidas? Cronograma.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
ViabilidadeEconômica:
- Apurar o retorno sobre o investimento (ROI) = Lucro Líquido/Investimento
- Quanto maior for o valor desse lucro, melhor é o ROI 
Engenharia de Requisitos:
- Elicitação -> Descobrir ou tornar explícito. Explicitando os Requisitos, onde se tem a 
descrições dos serviços fornecidos e restrições e características desses serviço.
- Tudo tende a Refletir as necessidades dos seus usuários.
Classificação - Requisitos:
- Requisitos de Usuários -> Abstração no nível mais alto e tem as seguintes definições:
- Descrição dos serviços esperados do sistema e restrições sobre as quais ele 
deve operar.
- EX: “O sistema deve controlar o bloqueio de exemplares pelo professor”
- Requisitos de Sistema -> É o detalhamento e tem as seguintes definições:
- Definir de forma estruturada e detalhada dos serviços e restrições operacionais.
- Ex: Detalhar as funções de bloqueio de exemplares.
Categorias de Requisitos:
- Funcionais -> Declarações de serviços que o sistema deve fornecer e como deve se 
comportar e pode estabelecer o que o sistema NÃO deve fazer. 
- Exemplo: Sistema deve informar melhor o aluno, sistema deve permitir incluir e 
excluir fornecedores.. Tipos de transações suportadas na conta..
- Não Funcionais -> Restrições sobre os serviços ou funções oferecidos pelo sistema e 
características ou qualidade.
- Exemplos: A impressão do boleto deve ser em no máximo 10 segundos, as 
dimensões dos relatórios devem ser configuráveis, além de restrições de 
hardware, ambiente e etc.. Tempo de resposta, facilidade de uso e tempo médio 
entre as falhas.. Confiabilidade.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Brainstorm
- Reunião onde participa todos os envolvidos.
Objetivos:
Permitir que todos expressem suas idéias de forma a obter um consenso.
Todos expressão de forma desorganizada mesmo, para depois organizar todas as idéias, 
identificar conflitos entre áreas e ideias e ter visões diferentes do requisito nas empresas.
Caso de Uso:
É na verdade um modelo da UML, usado para definir o escopo do sistema, identificar 
quem interage com o sistema (atores) e identificar os requisitos (casos de uso).
Usado apenas para Validar os requisitos com os usuários.
Não é em si uma técnica de levantamento de dados, mas o resultado é produzido após.
E esse resultado. que é o modelo(desenho) pode ser usado para validar os requisitos do 
usuário.
Os casos de uso nada mais é que as funções que o sistema tem.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
AULA 03
As fases da Análise de Requisitos
Estudar, entender e modelar o problema. A modelagem é criar modelos como referência 
para apresentar os requisitos.
- Modelos = Abstração da realidade. Exemplo: maquetes, protótipos.
É uma fase Independente de tecnologia.
Ela é estrutural, ou seja, como será as divisões do sistema e comportamental, de como as 
coisas vão funcionar no sistema. 
Técnica de Análise
- Estruturada / Essencial (Essa está obsoleta)
- Foco no funcional apenas.
- Eventos afetam o sistema - Funções são requisitos do sistema
- 3 visões apenas: Funções, dados e controle
- O sistema era um conjunto de processos.
- Orientada a Objetos (A usada na atualidade)
- O mundo é composto por objetos.
- A diferença entre Estruturada/Essencial é que o enfoque era apenas em 2 opções, 
dados e funções em módulos que interagem. Já a Análise Orientada a Objeto, são os 
objetos que interagem e o enfoque está integrada em atributos e métodos.
- O motivo é que os objetos existem antes de existir aplicações dele no negócio. 
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Objetos e Classes:
- Os objetos são os dados e as funções e podem ser encapsulados, ou seja, protegidos 
para acessos.
- As classes são formadas pelos objetos com as mesmas características.
- Os objetos trocam mensagens e os métodos/funções são os serviços que a classe 
presta tanto para ela mesma quando para o usuário.
- Com essa interação as mensagens trafegarão para a execução de uma tarefa.
A Análise em O.O serve para modelar o problema usando o conceito de objeto/classes e 
serve para mostrar para equipe de desenvolvimento com mais clareza os objetivos do 
sistema e para usuário, uma demonstração de como funciona e ele poder validar.
UML - Unified Modeling Language - Linguagem de Modelagem Unificada
É muito utilizada em engenharia de software e não é uma metodologia. Portanto, não diz 
para você o que fazer primeiro e em seguida ou como projetar seu sistema. Compreende 
uma série de diagramas 
 Diversos modelos de diagrama UML
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Exemplo de um diagrama de caso de uso:
O diagrama de caso de uso é usado para entender como funciona as funções que o 
sistema vai representar. As funções que estão em amarelo correspondem aos 
casos de usos principais que interagem com os atores e as que estão em azul, são 
funções de caso de uso segundarias. Este diagrama precisa de um complemento 
para mostrar as especificações dos casos de uso. Onde se tem uma declaração 
textual dos procedimentos e esse procedimento é fundamental, detalhando cada 
caso de uso ou função que o sistema vai fazer.
 Exemplo de Especificação de Casos de Uso
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
DIAGRAMAS DE CLASSES - CONCEITUAL
No diagrama de classes é representado cada classe do sistema e as cardinalidades 
dos objetos. Uma das características de um diagrama de classes e que ele vai 
crescendo com o projeto. Neste exemplo temos um modelo conceitual, uma forma 
mais amplas do sistema e está voltado para o modelo de negócio, ou seja, na fase 
primária da análise de requisitos.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
DIAGRAMA DE CLASSES - ESPECIFICAÇÕES
Neste modelo é possível entender outro nível de abstração para as classes e com 
mais especificações que no modelo conceitual. Portanto, está sendo acrescentado 
outros e mais outras classes.. Mostrando a características de que vai crescendo 
conforme o sistema.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
DIAGRAMA DE CLASSES - SEQUÊNCIA
Este diagrama de Sequência forma junto aos outros (Conceitual e Especificações) o 
tripé para a Análise. Cada cenário de casos de uso se tem um diagrama de 
sequência. Serve para ajudar na elucidação ou descobrindo novos métodos para o 
diagrama de classes especificações, através das interações entre as classes.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Aula 04
DESENHO DO SOFTWARE
Fases:
- Atenção aos requisitos -> via modelos de análise
- Como a solução deve ser implementada
- Como Fazer com detalhamento o funcionamento interno.
Visões do Projeto
- Externa - Visão do usuário 
- Modelo de Interação -> Interface/comunicação
- Interna - Componentes do Sistema
- Relação entre os componentes acoplados
- Funcionamento do componente
- Interconexões com outros sistemas.
NÍVEIS DE DESENHO DE SOFTWARE
- Estratégico
- Modelo geral da Arquitetura. Forma do sistema. Partes e relacionamentos. 
Sistemas e sub-sistemas. Quais os controles que vai ter. Uma maneira geral da 
aplicação.
- Tático ou Desenho Lógico
- Decisões tomadas no nível estratégico.
- Reutilização ou não de componentes do sistema. (Ajuda na economia)
- Operacional ou Desenho detalhado
- O Comportamento do componente.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
ARQUITETURA DO SOFTWARE
1) Estruturação do Sistema
- Estruturado em subsistemas e suas unidades independentes e a comunicação 
! entre os subsistemas
2) Modelagem de Controle
! -Modelo de relacionamento entre as partes de um sistema
3) Decomposição Modular
! - Cada subsistema é dividido em módulos.
- Modelo Orientado a Objetos
- Diagrama de classes
- Diagrama de componentes
- Interação com Diagrama de sequencia e diagrama de atividade.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
DIAGRAMA DE COMPONENTES
Este diagrama é muitoimportante para mostrar os módulos do sistema. Ele tá 
relacionado a Linguagem de Programação (Já escolhida) a usar e determina 
como os componentes se interagem e as divisões desses componentes que 
estão além das classes. O ponto forte do componente é para criar a 
possibilidade de reutilização do sistema. Um componente representa um 
empacotamento físico de elementos relacionados logicamente entre as 
classes.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
META - REUTILIZAÇÃO 
A ideia é usar o que já existe. Antes de fazer algo novo, é preciso saber se pode 
ser usado os componentes já existentes.
Isso reduz os custos e garante a segurança, pois os componentes já fora usados e 
testados.
NÍVEIS DE REUTILIZAÇÃO
Definições das demais atividades:
- Interface com usuário
- Arquitetura de Software e Sistema Operacional
- Linguagem de Programação
- Estrutura de Rede e comunicações
- SGBD - Banco de Dados
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Aula 05
TESTES
1‘ DEFINIÇÃO DE FASE DE TESTES
A fase de teste tem como objetivo detectar possíveis defeitos ou erros que possam surgir 
na fase de implementação.
! Nesta fase teste, deve-se coletar os resultados e analisá-los e consertá-los antes 
! de sua implementação.
Fase fundamental, muitas vezes renegada a segundo plano ou mesmo esquecida. Essa 
fase ajuda na incrementação da qualidade, na medida que avaliamos sob várias óticas.
TESTE OBJETIVOS CRITÉRIO PROCEDIMENT
O
“Script” de 
teste
Processo 
definido com 
intenção de 
encontrar 
um erro.
Encontrar um 
erro que ainda 
não foi 
descoberto. 
Um teste bem 
sucedido 
corresponde à 
descoberta de 
um erro 
previsto.
Definição de 
uma métrica 
que, após 
análise do 
comportamento 
do sistema, 
atenda o 
critério.
Conjunto de 
instruções para a 
realização do 
teste.
É uma 
representação 
definida de um 
procedimento 
teste.
Objetivo: Encontrar erros ainda não descobertos. Teste bem sucedido é aquele que acha 
erros não previstos. Para isso, é preciso usar e muito o produto.
Análise e verificação de todos os componentes do sistema.
! - Validar se estão em conformidade com os requisitos anteriormente definidos.
! - Para uma melhor análise, o teste deve ser feito por uma equipe independente, 
! diferente da equipe desenvolvedora.
MODALIDADES DE TESTES
-Testes estáticos ou Verificações
! - Feito antes da implementação (Não tem software pronto)
! - Inspeções, revisões, auditorias
! - Testes na fases iniciais - qualidade
! - Qualidade no processo
- Testes Dinâmicos ou Validações
- Durante ou após a implementação
- Precisa de parte ou todo sistema formado
- Qualidade no produto final
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Classificação quanto ao objetivo:
- Teste de Unidade (Programação o mesmo que implementação)
- Em unidades de programas
- Busca erros nos programas individuais
- Teste de Integração (Programação / testes)
- Identifica erros na integração dos diversos módulos, já testados individualmente.
- Teste de Validação (Testes)
- Realizado após a integração de todos os módulos
- Antes de Implantar o sistema.
Estratégias de Testes
Teste da Caixa Preta 
Não considera a forma como esta implementado - detalhes internos 
! Objetivos: 
! ! O software produz o resultado esperado?
! ! Os requisitos estão sendo atendidos também?
! Vantagens:
! ! Não requer conhecimento técnico da tecnologia emprega ou da
! ! implementação aplicada. Requer profissional menos capacitado.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Teste da Caixa Branca (Mais complexidade)
- Baseados na arquitetura interna do software com a verificação do código.
! - Objetivo:
! ! Identificar defeitos nas estruturas internas do software, através da simulação 
! ! que testem toda a estrutura usada na codificação.
! - Desvantagens:
! ! Requer conhecimento técnico da tecnologia emprega pelo software e 
! ! arquitetura interna da solução. São testes mais difíceis de serem
! ! implementados
! -Vantagens: 
! ! Eficiência na detecção de erros. 
! ! Em casos de testes que cubram todas as possibilidades de erro.
Testes de Unidades:
1° etapa do processo de validação
Teste Uma unidade: módulos/classes
Objetivo: 
Garantir a qualidade dos componentes do software individualmente avaliando:
! Estrutura interna -> Usar estratégia de caixa branca.
! Se a unidade atende aos requisitos -> Usar a caixa preta.
Teste de Integração:
- Natural continuidade dos testes de integração
- Verifica a compatibilidade da nova unidade com as demais, já prontas.
- Verifica se juntas e integradas, as unidades funcional e realizam o trabalho que o 
sistema precisa.
- Cuidado: Alteração de componentes.
- Geralmente. aplica-se estratégia da caixa preta, testando as interfaces entre as 
unidades. que se integram.
Teste de Sistemas ou chamado de Validação
- Estágio mais complexo da validação
- Validam a solução como um todo
- Aqui as falhas individuais já estão sanadas
- Ambiente (hardware, Sistema Operacional, rede etc) vem próximo da realidade da 
operação.
- Testar: integração com os sistemas externos, dispositivos físicos (Hardware)
- Dificuldade: Vislumbrar os vários cenários de uso
- Vários tipos: Stress, volume e performance do software.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Teste de Aceite:
- Homologação: (equipe)Interna e Externa(usuário)
- Último estágio do processo de validação _> último processo formal de detecção de erros 
no sistema.
- Uso por clientes e usuários -> validarem as funcionalidades
- Usuários interagem com o sistema completo
- Reduz o risco da entrega
IMPORTANTE
Planejar os testes
Documentar os testes
Validar ao longo do processo
Não queimar etapas de testes
Equipe especializada: Preferencialmente não ser equipe de desenvolvimento que façam 
os testes.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
AULA 06
IMPLEMENTAÇÃO 
A de implementação ou codificação tem o objetivo de escrever o programa em uma 
linguagem de programação e segue normas e diretrizes da empresa. As empresas 
seguem padrões para desenvolvimento.
Na fase de implementação, o programador detalha e implementa o que foi definido na 
etapa de desenho. através dos componentes de código de programa e documentação 
detalhada deste.
AS LINGUAGENS DE PROGRAMAÇÃO
Os computadores têm sua própria linguagem que são os números. Os números binários 
que seguem suas sequência eletrônica. Passado o tempo, construíram linguagens que se 
comunicam em forma de registros(montagem) com o computador e uma delas foi o 
Assembly. Essa linguagem é conhecida como baixo nível, pois trata com o computador o 
mais próximo da linguagem que o computador conhece. Depois vieram as linguagens de 
alto nível; que facilitaram a compreensão humana e o desenvolvimento com 
produtividade.
Homem = Alto Nível - Máquina = Baixo Nível
2 processos fazem esse papel 
! -INTERPRETADOR (Interpretação) -> Que traduz o código a medida que executa
! ! Linguagens: Python, Pearl, PHP, Javascript, ASP e etc..
! - COMPILADOR (Compilação) -> Traduz e depois executa o código 
! ! Linguagens: C, C++, Delphi e etc..
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
INTERPRETADOR (Interpretação):
- A interpretação(O Interpretador) é a tradução do código em linguagem de máquina em 
tempo de execução. Pode ser mal comparada a um tradutor simultânea de conversas.
- Uma das característica marcante das linguagens interpretadas é que seus códigos são 
executados até o ponto em que não ocorre um erro. Acontecendo um erro, a execução 
do programa é interrompida. 
- Por acontecer em tempo de execução, tipicamente as linguagens interpretadas tem um 
desempenho um pouco menor que as compiladas.
Exemplo de funcionamento da Linguagem Interpretada
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
COMPILADOR (Compilação) 
- Primeiro faz a leitura completa do código fonte,identifica variáveis e outros elementos e 
montando uma tabela (de símbolos) com estas informações.
- No segundo passo, a tradução do código em linguagem de máquina (código objeto). 
Entretanto, a compilação difere da tradução porque ela faz alterações no código, de 
forma a torná-lo otimizado.
- Tende a ter menos linhas na tradução, pois o compilador faz a otimização para melhor 
desempenho e confiabilidade na execução.
- Compiladores mais modernos conseguem grandes otimizações em certos códigos. Com 
isso os executáveis ficam menores e seu tempo de execução mais rápido.
- O Compilador varia de acordo com a arquitetura das máquinas. Pois ele converte as 
linguagens de alto nível para a linguagem de máquina dependendo da sua arquitetura.
- Existem Compiladores Híbridos que independem da arquitetura da máquina, pois gera 
um código objeto (bytecode) que conversa com uma Máquina Virtual antes da execução. 
Usado para portabilidade dos programas.
Exemplo de funcionamento da Linguagem Compilada
(Compilador / Compilador Híbrido
 
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Processo de Compilação em C (Compilador)
Todo esse processo é a compilação ou compilador..
1 - O Montador (Assembly) pega o código fonte e monta os objetos/módulos em 
linguagem de máquina
2 - o Link-Editor faz os links das bibliotecas utilizadas em linguagem de máquina e 
gera o código executável para a linguagem de máquina.
3 - O Loader carrega o programa para a memória.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Processo de Compilação em Java (Compilador Híbrido)
Neste processo o compilador ele gera um código comum para o interpretador gerar 
o bytecode para outras plataformas. 
Boas práticas de Programação:
- Documentação com comentários são essenciais para manutenção.
- Importante está datas e com assinatura de autoria dos componentes do código;
- Criar varáveis com nomes claros e coesos com sua utilização.
Programação em Par:
- Técnica usada nas metodologias ágeis (focado na programação e não na 
documentação).
- Onde 2 programadores trabalham em conjunto.
- 1 codifica e o outro verifica e eles se alternam nas tarefas.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Aula 07
MANUTENÇÃO:
- Início -> Quando o sistema é instalado no ambiente do usuário, para uso.
- Fim -> Quando o sistema torna-se obsoleto e é substituído.
- Motivos do fim do software e sua manutenção:
- Tecnologia ultrapassada
- Custo de manutenção supera benefícios.
O Ciclo de vida desse sistema = Ciclo de Vida de desenvolvimento + Manutenção. Logo, 
quando maior o tempo da fase de manutenção, maior a vida útil do sistema.
A qualidade da manutenção que implica no ciclo de vida do sistema, depende da 
qualidade do processo de desenvolvimento. 
Documentação atualizada e adequada, código eficiente e bem documentado.
 
Atividades da Manutenção:
- Temos o suporte ao uso, através de manuais, help desk, visitas e treinamento
- E temos também suporte ao desenvolvimento, como correção de erros que no início, 
pode ser alto o índice desses erros, que pode ter sido causada por ausência ou má 
qualidade dos testes.
- Temos também a melhoria das funções existentes no sistema.
- Podem ocasionar outros problemas como:
- O Efeito dominó - O mais comum, pois é quando uma arquitetura de 
software foi mal planeja e mexendo em uma função pode ocorrer erros em 
outras partes do problema.
- Soluções: Separação estática, que identifica o foco e isola para tratamento 
ou então refatoração, modificando a estrutura do software, sem alterar o 
comportamento dele.
- E a implementação de novas funções.
Afetam o tempo da Manutenção do software
- O tempo da manutenção define o tempo de vida do software
- Atentar sempre para o custo.
- Ter elementos altamente coesos (Funções próximas)
- Ter também elementos com baixo acoplamento. (Apartes devem ser independentes)
- Documentação completa e atualizada
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
fharaujo
Manutenção como Projeto:
Cuidado sempre com as novas versões, pois podem causar instabilidade no ambiente. O 
ideal é ter menos intervenção possível, acumular demandas que justifiquem a intervenção 
e tratar as demandas de manutenção com um projeto. Para que não tenhamos as 
dificuldades no controle da versão do software.
Como acumular Demandas:
Documentos de demandas dos usuários: 
- Data, Pedido, Tipo
- Tipo pode ser:
- Emergencial (imediato)
- E Melhoria - nova função 
Documentação para Suporte:
Manual do usuário:
- com linguagem clara e adequada ao perfil. Mostrar como o usuário usa as 
funcionalidades.
Manual de Introdução:
- Descreve as funcionalidades do sistema sob a ótica do uso
- Os pré requisitos necessários para operar as funcionalidades
Manual de Referência:
- Descreve as facilidades do uso do sistema;
- Informa os erros que podem ocorrer e como agir 
Documentação de Instalação:
- Descrição de como instalar o programa
- Plataforma de operação
- Pré-Requisitos necessários para instalação
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Aula 08
Contexto 
Anos 70/80, não era usado processo de desenvolvimento.
- Programadores baseavam-se nas próprias experiências
- Não havia forma definida estruturada de trabalho
- Não haviam testes e os erros eram corrigidos após a implantação.
MODELO CASCATA (Processo de Desenvolvimento)
Surge o Ciclo de Vida do Projeto
- Atividade ordenadas(pré-definidas), com fluxo contínuo para auxiliar o acompanhamento 
do projeto.
- Atividades
- Fluxo de Informações
- Relacionamento entre atividades
1º Modelo de Engenharia de Software 
- Linear -> A atividade é concluída antes de iniciar a próxima. 
- Sempre sequencial e pra frente em passo a passo.
- Útil para pequenos projetos da época
- Ganho na fase de planejamento 
- O problema era durante o projeto, a fase de requisitos, está em constante evolução e 
mudança e como o modelo era sempre pra frente.. Sem padronização e documentação.
MODELO CASCATA
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Características do Modelo Cascata
- Base para outros modelos
- Usado até hoje com suas fases
- Os processos não tem características sequências
- Sao desenvolvidos em porções de forma interativa-incremental 
- A questão: Se o processo somente pode ser seguido após a finalização de cada etapa 
anterior, este (projeto) nunca irá se encerrar..
- As vantagens: Fácil entendimento, permite pontos de controle bem definidos, o que 
facilita a gestão.
- Requer documentação em todas as fases do processo
- Em tese só se avança se o cliente aprova a fase atual
- Simples de implementar e gerir que é o seu maior vantagem.
- As desvantagens: Todos os requisitos devem ser descobertos no início, por não poder 
voltar a fase inicial depois da próxima etapa.
- Não é possível corrigir erros em fases completadas
- Projeto raramente segue o fluxo sequencial, pois as interações de vários ciclos são 
necessárias; coisa que o modelo não entendia como certo;
- Não se prevê manutenção.
- O usuário só vê os resultados ao final. O que é péssimo para o cliente.
- Dificuldade na visão de reutilização do sistema
- Se ocorrer um atraso, todo o processo é afetado
- Só o gesto tem visão do sistema como um todo
MODELO CASCATA COM RETROALIMENTAÇÃO
- Variante do Modelo “Cascata tradicional” que permite a realimentação do processo
- Este modelo permite a revisão de fases anteriores e a superposição entre fases
- Corrige-se os problemas que surgem durante outras fases passadas pelo processo.
- Porém, o custo dessa revisão/correção pode ser alto, dependendo da fase atual em que 
se encontra o processo e do quando se precisa retroceder.
- A grande vantagem desse modelo é de voltar para correção dos erros em outras etapas 
durante o processo de desenvolvimento do sistema e prevê a manutenção
- A desvantagem é quedependendo da quantidade de revisões e realimentações, o 
processo pode se tornar além de caro, difícil para se gerenciar.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
fharaujo
fharaujo
fharaujo
Aula 09
 Modelo de Processo Iterativo
Seleção de uma parte do projeto que identifica, especifica, implementa, testa e implanta a 
iteração. Quando atende as especificações, passa-se a próxima iteração. A ideia é dividir 
o processo em partes e trazer o usuário para ir moldando a implementações. Modelo é 
baseado na ideia de aumento do âmbito do sistema.
Modelo de Processo Incremental
Este modelo é baseado na ideia de aumento do sistema. Sua característica é o 
desenvolvimento em partes, onde as partes podem ser desenvolvidas, na criação de 
novas versões e em paralelo e integradas quando completadas. Neste processo também 
se tem o usuário participando antes da implantação do sistema pronto.
Modelo Iterativo e Incremental
A junção dos dois modelos define que deve existir um subconjunto e a utilização o modelo 
em cascata para sua realização.
Cada porção do ciclo desenvolvimento segue o projeto de arquitetura inicial como guia, 
mas com uma abordagem bem menor.
Uma vez satisfeitos os requisitos e os objetos da iteração, o desenvolvimento seque para 
a próxima iteração(pedaço).
Modelo Prototipação 
É um modelo que ser para ser analisado e desenvolvido a partir do protótipo. Onde o 
Analista coleta informações para um mini projeto, concentrando-se nas entradas e 
saídas do software. Depois da criação e aceitação do protótipo, o produto final será 
desenvolvido. O protótipo ser como um mecanismo para identificar os requisitos.
Os Tipo de Protótipos:
- Em papel ou sistema: que retratam a interface e interação do software
! Quando em sistemas, ele implementa algumas funções:
! ! Como usar?
! ! - O cliente definiu um conjunto de objetivos gerais para o software, mas não 
! ! identificou requisitos de entrada, processamento e saída com muitos 
! ! detalhes.
! ! - O desenvolvedor não tem certeza da eficiência de algum algoritmo ou 
! ! forma de interação.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Características Principais da Prototipação
1 - Obtenção dos Requisitos
O desenvolvedor e o cliente definem os objetivos gerais do softwares, identificando quais 
os requisitos são conhecidos e as áreas que necessitam de definições.
2 - Projeto Rápido
É a representação dos aspectos do software que são visíveis ao usuário(entrada e 
formatos de saída)
3 - Construção do Protótipo
É a implementação do projeto rápido. Serve como o “primeiro sistema” e é recomendado 
que não seja usado como produto final, ou seja, como exemplo um janela e seus menus.
4- Avaliação do Protótipo 
Cliente e desenvolvedor avaliam o protótipo feito
5 - Refinamento dos Requisitos
Com base na avaliação, são definidos melhorias ou refinamento do produto.
Ocorre neste ponto o processo de iteração que pode conduzir para atividade 1 até que as 
necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa 
ser feito.
6 - Construção Final do Produto
A versão de produção deve ser construída considerando os critérios de qualidade que 
foram feitos na avaliação e refinamento. A partir daqui o protótipo já pode ser descartado.
Modelo Espiral
Neste modelo se assemelha com o protótipo, mas inclui um fator que é a análise de risco
Ele funciona de forma iterativa, incremental, mas com uma etapa onde pode ser tomada a 
decisão de interromper ou não o processo.
Cada volta do espiral representa uma fase do processo
Planejamento -> Definições e restrições 
Análise de Riscos -> Análise de alternativas e identificação dos riscos sob o ponto de vista 
técnico e de gerência.
Engenharia - > Desenvolvimento do produto.
Avaliação do Cliente -> Que é a avaliação dos resultados.
Não há fases fixas e as voltas na espiral são determinadas pelo que é requerido.
Todo o risco é avaliado e resolvido no processo.
Engloba as melhores características do ciclo de vida Clássico em Cascata e da 
Prototipação. Adicionando um novo elemento que é a Análise de Risco.
Usa principalmente a Prototipação em qualquer etapa da evolução do produto, como o 
mecanismo de redução de riscos.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
As Vantagens do Modelo Espiral:
- Modelo evolutivo, possibilita a integração entre as fases e facilita a depuração e a 
manutenção do sistema
- Permite que o projetista e cliente possam entender e reagir aos riscos em cada etapa 
evolutiva.
As Desvantagens do Modelo Espiral:
- Avaliação dos riscos exige muita experiência
- O modelo é relativamente novo e não tem sido amplamente utilizado.
Tela Comparativas de Modelos
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Aula 10
 Metodologia Ágeis 
Contexto do Estado da Arte do Desenvolvimento de Software
- Engenharias tradicionais valorizam o projetar antes de construir
- Ela não enxergam o processo de desenvolvimento de software como ele realmente é: 
Com mudanças sempre e o tempo todo
- Então surgiu a necessidade de mudanças na metodologia que permita alterações 
frequentes do software sem afetar sua qualidade.
- Um grupo de desenvolvedores passou a conceber a ideia de um processo menos 
burocrático e + prático. Da aí vai nascer a metodologia ágil.
Processo de Desenvolvimento Ágil:
- Ele é baseado em um manifesto criado por desenvolvedores experientes.
- Que visa o descobrimento de maneiras de melhor desenvolver software, fazendo nós 
mesmo e ajudando outros a fazerem.
- O Foco em pessoas e não em ferramentas
- Mudanças de valores.
Manifesto Ágil:
- Valoriza-se:
- Indivíduos e interação mais que o processo e ferramentas
- Software em funcionamento mais que documentação abrangente 
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudança mais que seguir os planos
- A maior prioridade é satisfazer o cliente
- Mudanças nos requisitos são bem-vindas. mesmo que tardiamente no 
desenvolvimento
- Entregar frequentemente software funcionando - na menor escala de tempo 
possível.
- Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto 
por todo o projeto.
- Construir projeto em torno de indivíduos motivados. Dê a eles o ambiente e o 
suporte necessários
- O método mais eficiente e eficaz de transmitir informação para e entre uma 
equipe de desenvolvimento é através de conversa
- Software funcionando é a medida primária de progresso.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Modelo Ágil - Método XP (eXtreme Programming)
- Baseado em 5 valores:
- Comunicação
- Coragem para lidar com as mudanças de requisitos
- Feedback
- Respeito entre membros da equipe
- Simplicidade ao fazer o necessário
Práticas do Método XP:
- Reuniões em pé - Para não perder o foco do assunto.
- Programação em par - Um iniciante e outro instrutor, utilizando um computador e ambos 
aprovam o código.
- Testes de aceitação pelo cliente.
- Processo Coletiva - O código fonte pertence a ninguém e todos podem utilizá-lo.
- Pequenas Versões - Aceitas pelo cliente ajudam na aceitação do programa completo.
- Ritmo sustentável - Trabalho de até 40h semanais sem acréscimo.
- Padrão de Codificação - Com regras claras de código de programa.
Modelo Ágil - Método Scrum:
- O Scrum é um processo de desenvolvimento interativo e incremental para 
gerenciamento de projetos e desenvolvimento ágil de software.
- Uso: Trabalhos complexos, onde não há previsão exata o que se pretende desenvolver
- O projeto é dividido em ciclos(sprints)
- O sprint é a iteração em um modelo Scrum.
Práticas do Método Scrum
Product Backlog -> Lista com funcionalidades a serem implementadas.
Sprint Backlog -> Análise dos requisitos para informar a equipe como será 
implementado.
Sprint -> Período para finalização de cada requisito.
Scrum -> Reuniões diárias paraanálise de andamento do processo.
Scrum Master -> Coordenador do sistema - Não pode estourar o sprint.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
fharaujo
fharaujo
RUP - Rational Unified Process ( Processo Unificado Rational de Desenv.)
- Processo proprietário de desenvolvimento de software, criado pela Rational, que 
foi adquirida pela IBM.
- Baseado em conceito Orientação a Objeto
- Processo Pesado - Rigidez 
- Uso de grandes projetos
- Desenvolver interatividade - Porções colocadas aos poucos.
- Gerenciar requerimentos - Uso de Casos de Uso
- Foca na arquitetura baseada em componentes
- Utiliza UML - Modelo Visual
- Qualidade durante todo o processo 
- Gestão e controle de mudanças
Práticas do Método RUP:
- Disciplinas são técnicas + em Fases + nas Interações
- Disciplinas
- Modelagem de negócios - Tem que se entender o negócio da empresa;
- Requisitos
- Análise e design
- Implementação
- Testes
- Configuração e mudanças
- Projeto(Gestão de pessoas, orçamento e contratos)
- Ambiente(Servidores, ferramentas, Bds..)
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE