PROCESSO DES SOFTWARE

Prévia do material em texto

Aula 1 
O que é software? 
É uma sequência de instruções organizadas de maneira que, ao iniciá-lo, tem como objetivo executar, manipular ou 
modificar um dado, informação ou acontecimento. 
O Software, por sua vez, também é considerado um produto que foi desenvolvido pela Engenharia de 
Software que inclui, além do programa propriamente dito, manuais e especificações. 
 
O software. 
Para o desenvolvimento do produto/programa, é necessário escrevê-lo utilizando uma linguagem de programação 
que será responsável por converter o código em linguagem de máquina, ou seja, em um formato que será 
compreendido pelo processador. 
 
Existem basicamente duas classificações para a linguagem de programação. 
 
Além da linguagem de programação, o software também pode ser classificado como: 
 Software de Sistema 
"Também chamados de sistema operacional, é responsável por operar os demais periféricos que estejam conectados 
ao hardware." 
 
Pode ser classificado quanto ao gerenciamento de processos como: 
• Monotarefa: Executa somente um processo de cada vez. 
• Multitarefa: Os processos são compartilhados e enfileirados a espera do processador. É distribuído de modo que 
pareça ser executado simultaneamente. 
• Multiprocessamento: Distribui para mais de um processador. 
• Monousuário: Somente é permitida a utilização de um usuário de cada vez. 
• Multiusuário: Vários usuários utilizam ao mesmo tempo. 
 Software aplicativo 
Diversos outros programas que têm interface direta com o usuário, como editores de texto, planilhas eletrônicas, 
navegadores, dentre outros. 
 
Características e aplicações do software. 
O software pode ser classificado de acordo com a sua licença de publicação; ele pode ser, dentre outros: 
 Software Gratuito ou Freeware: Programa de computador cujo uso não implica o pagamento de licença de 
uso. 
 Software Livre: Programa de computador cuja utilização, cópia e distribuição não possui restrição. É comum 
o código fonte estar disponível para manuseá-lo.. 
 Shareware: Programa de computador que possui limitações de tempo e/ou funcionalidades. Ao final do 
tempo estabelecido, o programa pode requisitar o pagamento para uso do software completo ou pode 
continuar rodando sem todas as suas funcionalidades ou, ainda, interromper o seu uso.. 
 Adware:Programa de computador que executa automaticamente algum tipo de publicidade após sua 
instalação ou durante sua utilização. 
 Demo: Fração de um programa. Funciona como material promocional para dar a oportunidade do produto ser 
avaliado. 
 Trial: Programa semelhante ao demo, mas com funcionalidades disponíveis por tempo determinado. 
 Comercial: Programa por que se paga uma taxa de licenciamento para sua utilização. 
 
 
 
 
SISTEMA DE INFORMAÇÃO 
• Sistema = Conjunto de partes, independentes, cada qual com seu objetivo e colaborando por um objetivo 
comum. 
• Informação = Dados (fatos isolados) agrupados e relacionados (processados), com sentido lógico. 
– Dados: chq 1235 de 1.250,00, chq 1236 de 750,00 
– Dado: saldo Anterior é 5.000,00 
– Informação: Saldo Atual é 3.000,00 
• Sistema de Informação = Conjunto de elementos inter-relacionados que coleta (entrada), manipula 
(processamento), armazena a dissemina (saída) informações 
• Manual 
– Processa pouco volume de dados 
• Baseado em computador (Usa TI) 
– Hardware (componentes físicos – desgastes) 
– Software (componentes lógicos) 
– Banco de dados (armazenamento) 
– Telecomunicações (rede, internet) 
– Pessoas (mais importante. Fazem a diferença) 
– Procedimentos e processos (organização) 
• O valor de um SI depende da qualidade de seus componentes. 
– Excelentes algoritmos codificados em seu software X péssimo desempenho por defeito na 
especificação do hardware, rede ou BD 
– Cada um de seus elementos pode por em cheque a confiabilidade e usabilidade do SI 
• O engenheiro de software precisa saber a quem chamar quando o problema não for especificamente no 
software. 
• A Tecnologia não faz milagre !!! 
• Os problemas com sistema de informática podem ter várias causas 
– As pessoas que operam o sistema podem ser mal qualificadas. Investimento em treinamento 
– Processos de negócios inadequados (no qual o sistema esta inserido) 
– Deficiência do próprio sistema. Tecnologia inadequada 
SOFTWARE 
• Porção lógica de um SI, que comanda a operação do computador. 
• Tipos de Software, quanto a natureza 
– Software de Sistema: controlam as operações do computador: software da BIOS, S.O., L.P. 
– Software aplicativo: interface direta com usuário 
• Software hoje – Como administrar? 
– Grandes e Complexos (envolvem toda organização) 
– Demandam rápidas mudanças. 
• Responsável por prover o produto mais importante de nossa sociedade: a informação. 
• Melhorias nos últimos 50 anos: Hw, BD, Redes – aumento capacidade de processamento + diminuição dos 
custos 
• Por que SW não acompanhou? 
– Por que levar tanto tempo para concluir o SW? 
– Por que os custos do SW são tão elevados? 
– Por que não achamos o erros antes da entrega? 
– Por que os custos de manutenção são altos? 
• Processo de desenvolvimento do HW é um sucesso. O do SW não. Por que? 
Hardware Software 
Fabricado Manufaturado 
Falhas Inicio 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 SW depende MUITO do componente humano. 
– Há pouca automação no desenvolvimento. 
– Visão de projeto inadequada. 
• Histórico: gestor de TI sem formação em ADM. 
• Gestão (planejamento, organização e controle) de prazos e custos ineficiente 
– Pressão dos usuários/clientes: rapidez. 
• Daí os problemas 
– Prazos, Custos, Comunicação 
 
CICLO DE VIDA DO SW 
• 1. Começo: percepção de necessidades. 
• 2. Desenvolvido, transformado-se em um conjunto de itens a ser entregue ao usuário 
• 3. Entra em operação, sendo usado dentro de um processo de negócio e sujeito a atividades de 
manutenção. 
• 4. Fim: é retirado de operação ao final de sua vida útil. 
COMO DESENVOLVER? 
• Passado 
– Necessidades  Programação (CAOS) 
• Hoje 
– Projeto e Processo de desenvolvimento 
• Qual a finalidade do SW? 
• Quais as funções o SW terá? 
• Como essas funções se integrarão? 
• Como o SW se integrará ao contexto da empresa? 
• Quanto tempo terei para construí-lo? 
PROCESSO 
Conceito de Processo 
• Maneira pela qual se realiza uma operação, segundo determinadas normas 
 O método da engenharia se baseia em uma ação sistemática e não improvisada. 
 
PROCESSO DE DESENVOLVIMENTO 
 
 
Organização das fases, estabelecendo: 
• Quais são elas? 
• Finalidade de cada uma? 
• Ordem e ligação entre elas? 
• Funcionamento do processo 
• Documentação e modelos de cada fase 
CONCEITOS FUNDAMENTAIS 
• Escopo – Abrangência 
– Compreende o que será considerado para o desenvolvimento. 
– Quanto maior o escopo, maior é a complexidade e dificuldade de gerenciar o desenvolvimento. 
AT IVIDADES
 TAREFAS
 SUBPROCESSOS
 PROCESSO
• Requisito = Necessidades do usuário 
– Compreende as funcionalidades que o sistema deve possuir. 
• Fundamental – Definir os requisitos que farão parte do escopo. 
CONCEITOS FUNDAMENTAIS 
• Problemas e erros de requisitos são os mais caros de resolver. 
– Quanto mais o tempo passa, pior 
• Problemas 
– Má definição do escopo do sistema (má atuação profissional). 
– Rápida mudança de escopo (atualidade) 
• Ou seja Atenção TOTAL aos Requisitos 
ENGENHARIA DE REQUISITOS 
• Problema – levantamento e documentação de requisitos 
– Boa documentação – boaschances de atender aos requisitos 
– Boa especificação de requisitos - fundamental 
• Engenharia de Requisitos 
– Técnicas de levantamento de requisitos 
– Documentação. 
– Análise de Requisitos 
GESTÃO DOS REQUISITOS 
• Problema: Instabilidade nos Requisitos 
– Novos requisitos e Alterações de requisitos com o desenvolvimento já adiantado. 
– Alto custo, Re-trabalho, perda de trabalho feito 
– O mesmo que alterar a planta estrutural de uma casa, após iniciada a 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 prazos e 
custos. 
– Ouve-se muito: “não me interessa o que você vai dizer ! Preciso disso em 1 mês”. 
• A questão: No início só temos requisitos. 
– É difícil medir os programas necessários com base me requisitos. 
– Após projeto detalhado se conhece melhor os detalhes. Mas usuário não espera. 
• É preciso 
– Planejamento e controle de projetos 
• Análise dos riscos (probabilidade de sua ocorrência e ações corretivas, caso aconteçam) 
• Acompanhar o progresso do projeto 
• Renegociação dos prazos e custos 
– Garantir a qualidade do processo 
• Garantia = conformidade com requisitos 
• Qualidade do produto é influencia da pela qualidade no processo 
• Quanto ANTES um problema for identificado e resolvido, melhor (menos custo) 
PROBLEMAS NO PROCESSO 
• Software atual é: complexo, grande e com interface com demais sistemas. 
• Necessidade de equipe grande, competente e interdisciplinar. 
• O tempo geralmente é grande. 
• Ou seja a gestão do processo de desenvolvimento está mais complexa 
• Facilitador: Ferramentas de automação (case) 
 
 
 
 
 
 
 
 
 
 
 
Aula 2 
O entendimento das atividades da chamada engenharia de requisitos permite reduzir os erros decorrentes dessa fase 
que corresponde ao inicio do ciclo de vida do processo de desenvolvimento de software. 
Atividades para análise de requisitos 
Estudo de viabilidade: estudo inicial para saber se vale a pena desenvolver a ideia. O estudo deve oferecer 
base para ajudar nessa decisão: 
O projeto/produto pode ser feito? 
O projeto/produto beneficiará os clientes interessados? 
Existe uma outra alternativa? 
A. TÉCNICA - Visa a atender os requisitos técnicos do produto a ser desenvolvido. O levantamento deve ser 
relacionado com a tecnologia envolvida no processo de desenvolvimento. 
B. OPERACIONAL - Visa atender os requisitos para a aceitação do produto ou problema apresentado. 
Levantamento deve ser relacionado com a aceitação da solução proposta, e como os agentes se sentirão em 
relação à ela. 
C. CRONOGRAMA- Visa a atender os requisitos de tempo para os prazos estabelecidos. O levantamento deve 
ser baseado na viabilidade técnica em relação ao prazo estipulado. Prazos obrigatórios são mais difíceis de 
serem negociados. 
D. ECONÔMICA - Visa a atender os requisitos financeiros do projeto/produto. Considerada a mais critica, ela 
consiste em julgar se o projeto será deficitário ou se os custos de sua implementação não terão os benefícios 
desejados. Esta fase tambem é chamado de analise de custo-beneficio. 
Operacional e no desenvolvimento do projeto. 
Operacional: fixo e contínuo. Ex. custo com pessoal, manutenção, luz 
Desenvolvimento do projeto: aquisição de novos softwares, custos de instalação, atualização. 
 
Análise de ROI 
Percentual que mede a relação entre quanto se ganhou e quanto se investiu. 
 
1. REQUISITO - É uma condição ou necessidade de um usuário para resolver um problema ou alcançar um 
objetivo. Também pode ser uma necessidade de estar presente em um sistema para satisfazer uma 
condição, contrato, padrão, ou especificação devida. 
2. REQUISITO DO USUÁRIO - Definições sobre a função do sistema e restrições sob os quais ele deve operar. 
O formato é em linguagem comum, visando ao entendimento do cliente/usuário. 
3. REQUISITOS DO SISTEMA - Definição estruturada e detalhada do serviço que será feito no 
sistema/produto. O formato é em contrato de prestação de serviço entre o cliente e o fornecedor. 
4. REQUISITOS FUNCIONAIS - Descrevem as funcionalidades do sistema. Estão diretamente ligados às 
especificações da tecnologia envolvida, do perfil do usuário, do tipo do sistema. 
 
5. REQUISITOS NÃO FUNCIONAIS 
 
 
 
 
Técnicas de elicitação 
ENTREVISTAS: Utilização na análise de problema e na engenharia de requisitos com o objetivo de entender 
as perspectivas do cliente/usuário. Entender quem são os agentes e quais as necessidades, o problema e a 
solução. 
CASOS DE USO: Identificação dos agentes que agem no sistema, das interfaces que o o sistema/produto 
possuirá, validação de pré-requisitos. Representação visual ao invés de textual. 
QUASTIONÁRIOS: Forma de utilização que faz perguntas referentes ao sistema. Utilização de hipóteses 
para as relevâncias. Podem ser utilizados após a entrevista. 
BRAINSTORM: Ou tempestade de ideias, faz o levantamento de ideias, em que cada uma sugerida pode 
combinar na propositura de uma nova. Atividade de livre imaginação que deve ser tratada sem críticas ou 
debates. 
REVISÃO 
• Processo de desenvolvimento 
• Conjunto de fases, cada qual com uma finalidade, que descrevem passo a passo, formalmente, o 
que devem ser feito para desenvolver um sistema. 
• Cria um padrão, para todos seguirem 
• Confere qualidade ao software 
ESTUDO DE VIABILIDADE 
• Concepção 
• Semente  Necessidade, idéia 
• O que é o sistema? – definições iniciais 
• É viável?  Vale a pena? 
• Estudo ou Análise de Viabilidade 
• Benefício deve superar o Custo? 
• Empresa 
• Negócio a que se destina 
Entrada: 
1. Conjunto preliminar de requisitos de negócio 
2. Esboço da Descrição do Software 
3. Como apóia a área de negócios 
 
Saída: 
1. Viável? (técnica, operacional e financeiramente) 
ANÁLISE DE VIABILIDADE 
 O SW contribui para os objetivos da organização? Beneficia os interessados? 
 Viabilidade Operacional 
 O SW pode ser implementado com TI atual? 
 Viabilidade Técnica 
 Restrições de custo serão atendidas? 
 Viabilidade econômica 
 Restrições de prazo serão atendidas? 
 Cronograma 
VIABILIDADE ECONÔMICA 
• Apurar o retorno sobre o investimento (ROI) 
– % que mede a relação entre o quanto se ganha (pretende ganhar) e quanto se investe. 
• ROI=(Lucro Liquido)/Investimento 
– Lucro Liquido = receitas – despesas (todas) 
– Investimento = Tudo que será investido para o sistema: Softwares, Hardware, Redes, obras e etc. 
Quanto MAIOR O VALOR, melhor o ROI 
 Investimento = R$ 40.000,00 
 Desenvolvimento: 20.000 
 Softwares: 5.000 
 Hardware + rede + Internet: 10.000 
 Mobiliário: 5.000 
 Receitas (Vantagens) com sistema: R$ 15.000,00 
 Despesas com sistema = R$ 5.000,00 
 Lucro Líquido com sistema = R$ 10.000,00 
 ROI = 10.000,00 / 40.000,00 = ¼ = 0,25 
Conclusão: O investimento se paga em 4 anos. 
ENGENHARIA DE REQUISITOS 
• Elicitação  Elicitar = descobrir, tornar explícito. 
– Explicitar o que? Resposta: Requisitos 
• Requisitos (necessidade do usuário) 
– Descrições dos serviços fornecidos pelo sistema. 
– Restrições e características desses serviços 
Refletem a necessidades dos seus usuários 
CLASSIFICAÇÃO:REQUISITOS 
• Requisito de usuário (abstratos- nível alto) 
– Descrição dos serviços esperados do sistema e restrições sobre as quais ele deve operar 
– “O sistema deve controlar o bloqueio de exemplares pelo professor” 
• Requisito de Sistema (detalhado) 
– Definição estruturada e detalhada dos serviços e restrições operacionais– Detalhar as funções de Bloqueio de exemplares 
REQUISITOS DE SISTEMAS 
• Funcionais 
– Declarações de serviços que o sistema deve fornecer e como deve se comportar. 
– Pode estabelecer o que o sistema NÃO deve fazer 
• Não Funcionais 
– Restrições sobre os serviços ou funções oferecidos pelo sistema 
– Características ou qualidades 
EXEMPLOS DE REQUISITOS 
• Funcionais 
– RF: Sistema deve informar melhor aluno 
– RF: Sistema deve permitir incluir e excluir fornecedores 
• Não Funcionais 
– RNF: A impressão do boleto deve ser em no máximo 10 segundos 
– RNF: as dimensões dos relatórios devem ser configuráveis 
– Restrições de hardware, ambiente e etc 
• Exemplo: Sistema de Caixa Eletrônico 
– Tipos de transações suportadas na Conta 
• Funcional 
– Tempo de resposta, facilidade de uso e tempo médio entre as falhas 
• NÃO Funcional 
ENTREVISTA 
• Quandousar? 
– Primeira técnica a ser usada com alto escalão para entendimento da organização (organograma). 
• Fechadas (questionário) ou abertas (roteiro) 
• Individual oupequenogrupo 
• V - Eficiente 
• D - Cara (falta de tempo das pessoas). 
• V- Permite observar postura corporal. “Olharnosolhos”. 
• D - Cuidado: não se perder (roteiro) 
QUESTIONÁRIO 
• Quando usar? 
– Muitos usuários e há necessidade de uma análise estatística. 
– Falta de tempo dos envolvidos para entrevistas. 
– Usuários estão geograficamente distantes (pesquisa de satisfação na Estácio) 
• Evitar: perguntas abertas. 
– O que você do procedimento atual... ? 
• Focar: perguntas direcionadas ao que se deseja saber. Exp: Considera o procedimento atual 
– ( ) Ruim ( ) Satisfatório ( ) Ótimo 
BRAINSTORM 
• Reuniões onde participam todos os envolvidos 
• Objetivo: permitir que todos expressem suas idéias de forma a obter o consenso. 
• Todos expressão de forma desorganizada mesmo 
• Organizam-se as idéias 
• Identifica-se conflitos entre áreas 
Visões diferentes do requisito nas empresas. 
CASO DE USO (CUIDADO) 
• É na verdade um modelo da UML, usado para: definir o escopo do sistema, identificar quem interage com o 
sistema (atores) identificar os requisitos (casos de uso), 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 com os usuários. 
 
OUTRAS TÉCNICAS 
• Observação “in locco” – analista se insere no dia a dia da empresa. Constatar o que foi levantado e entender 
funcionamento na prática. 
• Análise de documentos 
• JAD – excelente para projetos que necessitam discussão de várias áreas da empresa. 
 
 
 
 
 
 
 
 
 
 
AULA 3 
Atividade de análise no processo de desenvolvimento de softwares 
A fase de análise tem como objetivo fazer uma modelagem dos agentes, separando-os em objetos, classes e 
atributos. 
A análise pode ser estrutural ou comportamental. 
Conceito de Modelagem 
Modelagem: Serve para verificar a qualidade dos requisitos, estudados na aula anterior, que se tornarão precisos e 
detalhados o suficiente para as atividades do próximo passo no processo de desenvolvimento de software. 
Análise: Atividade que utiliza o conceito de orientação a objeto, utilizando a UML como notação. Tem como objetivo 
modelar o problema, não a solução. 
UML: Unified Modeling Language, linguagem de modelagem unificada, utilizada em engenharia de software para 
visualizar o desenho do sistema e a intercomunicação entre objetos. 
Objeto e classe 
OBJETO: Estrutura de dados encapsulada por procedimentos. Essa estrutura são os atributos e operações. 
CLASSE: Conjunto de objetos similares agrupados em que a etapa de análise está mais voltada para sua realização. 
Tipos de análise 
Análise Estrutural : Tem como objetivo modelar aspectos estáticos de um problema, utilizando o modelo orientado a 
objeto. É utilizada em conjunto com detalhamento de requisitos para visualizar e fornecer base para identificar 
soluções para os requisitos apresentados. 
Atividades dentro da análise estruturada 
 IDENTIFICAÇÃO DE CLASSE 
Identificar quais são as classes chaves. 
Fazer o levantamento com base em suas responsabilidades e colaborações. Utiliza-se em larga escala o cartão CRC 
( Class-Responsability-Collaborator). 
 ORGANIZAÇÃO DE CLASSE 
Organizar as classes em três tipos: 
Entidade: representa conceitos do domínio do problema herdada dos modelos de negócio. 
Fronteira: representa interfaces externas que estão dentro do produto, como interface de usuário e conexão com 
outros sistemas. Facilita o desenho das interfaces. 
Controle: organização que não pertence à entidade e nem à fronteira. Normalmente é associada a um caso de uso. 
 IDENTIFICAÇÃO DOS RELACIONAMENTOS 
Identificação dos relacionamentos: ajuda a filtrar e refinar as classes. 
Pode se por: 
Associação: indica a relação entre duas classes em que o objeto de uma classe consegue obter informações da 
outra a que foi associado. 
Agregação: indica um associação, mas com a classe se apossando das informações de um objeto da outra. 
 IDENTIFICAÇÃO DOS ATRIBUTOS 
A cada classe é atribuída uma característica responsável por tomar alguma ação. 
 ANALISE COMPORTAMENTAL 
Aplicada depois que os requisitos forem detalhados, validando-os e indicando as dificuldades de implementação no 
plano de conceito. 
 DIAGRAMA DE INTERAÇÃO 
Mensagens que são trocadas, ao longo do tempo, para execução de alguma tarefa. 
Mensagens e Operações: representam um mecanismo de interação, ou seja, um objeto só poderá receber uma 
mensagem invocada por uma classe. 
A mensagem tem as seguintes partes: 
 
Interação: como as mensagens trafegarão para a execução de uma tarefa. 
 Diagrama de sequência: ordem temporal das ações que serão executadas. 
 INDENTIFICAÇÃO DAS OPERAÇÕES 
Todas as mensagem devem se mapeadas para executarem alguma operação. 
Podem ser: Incluir, Alterar, Excluir, dentre outras. 
FASE: ANÁLISE 
• Estudar, entender e modelar o problema 
• Modelar = criar modelos para apresentar os requisitos 
– Modelos= abstração da realidade 
– Exemplos: maquetes, protótipos 
• Independe de tecnologia 
• Estrutural 
• Comportamental 
TÉCNICAS DE ANÁLISE 
• Estruturada / Essencial (obsoleta) 
– Eventos que afeta o sistema  funções 
– Foco: funcional 
– 3 visões: funções, dados e controle 
– Sistema = conjunto de processos 
• Orientada a objeto (atual) 
– O mundo é composto por objetos 
MUDANÇA DE ENFOQUE 
• ESTRUTURADO / ESSENCIAL 
– Sistema = Módulos que interagem 
– 2 perspectivas isoladas: dados e funções 
• ORIENTADO A OBJETO 
– Sistema = objetos que interagem 
– Única perspectiva integrada: atributos e métodos 
• MOTIVAÇÃO 
Objetos existem antes de existir aplicações dele no negócio 
 
 
ENCAPSULAR = ESCONDER 
 
 
OBJETOS E CLASSES 
 Objeto: Dados + Funções 
 Encapsulamento 
 Classe = Objetos com as mesmas características 
 Análise O.O = modelar o problema usando o conceito de objeto/classe. 
 
FUNCIONAMENTO O.O 
 Objetos trocam mensagens 
 Métodos=serviços que a classe presta 
 Interação = como as mensagens trafegarão para a execução de uma tarefa. 
UML 
 Unified Modeling Language 
 Linguagem de modelagem unificada, utilizada em engenharia de software 
 Não é uma metodologia. 
 NÃO diz para você o que fazer primeiro e em seguida ou como projetar seu sistema 
 Compreende uma série de diagramas 
DIAGRAMAS UML 
 
 
Diagrama de Casos de Uso 
 
Especificação Casos de Uso 
• Declaração textual do procedimento correspondente ao caso de uso. 
• Passo a passo para realização do caso de uso 
• Mostraa interação do usuário com o sistema. 
• Detalha o requisito 
• Complementa o diagrama. 
• FUNDAMENTAL. 
 
 
 
Diagrama de Casos de Uso 
 
Especificação Casos de Uso 
Definição do Caso de uso : Emprestar Fita 
 
Roteiro do Caso – Fluxo Principal 
1. Atendente informa identificação do Sócio ao Sistema 
2. Executar caso de uso “Pesquisar Sócio” 
3. Para cada fita a ser emprestada 
1. Atendente informa fita 
2. Executar caso de uso “Pesquisar Fita” 
4. Atendente confirma os dados 
5. sistema registra os empréstimos. 
Fluxos Alternativos 
2a. – Cliente não cadastrado. Sistema exibe esta msg e encerra o caso 
2b. - Cliente está em Débito. Sistema exibe esta mensagem e encerra caso. 
3a. Fita não está cadastrada. Sistema exibe msg e encerra o caso 
DIAG CLASSES-Conceitual 
 
 
DIAG CLASSES-Especificação 
 
DIAG CLASSES-Implementação 
 
DIAGRAMA DE SEQUENCIA 
 
 
: TelaSaque
Correntista
senha
C1: ContaCorrente
validarSenha(senha)
saque
verificarSaldo()
bloquearValor(saque)
debitarValor(saque)
aviso de liberação
L1: Lancamento
efetuarLancamento(C1)
efetuarLancamento(C1)
TRIPÉ DA ANÁLISE 
 
 
 
 
 
 
 
Aula 4 
O DESENHO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
A fase de desenho tem como objetivo modelar o sistema, atendendo os requisitos levantados na fase de análise, e 
prepará-los para a implementação. 
O desenho do produto ou solução mostra como deve ser implementado, mas não envolve qual o tipo de tecnologia 
especifica necessita para fazê-lo 
Problema vs. Solução 
PROBLEMA: Levantamento de informações na fase de análise e requisitos define-se como um problema ou meta a 
ser alcançada. 
SOLUÇÃO: Após levantamento de análise, a documentação do desenho exemplifica a solução que será tomada 
para resolução do problema. 
Modelos de desenho 
DESENHO EXTERNO: Visão que os usuários terão da solução ou produto e a forma com que eles interagirão. 
DESENHO INTERNO: É a maneira como o sistema interage com outros produtos ou sistemas. Podem conter parte 
físicas, lógicas, interconexões com outros sistemas e produtos, interna ou externamente. 
 
O nível de abstração e agregação dos elementos dos sistemas podem ser: 
 
Nível estratégico ou desenho arquitetônico 
É o corpo da arquitetura do sistema a ser implementado. Com 
base nesse desenho, já se pode saber se o sistema atenderá 
aos requisitos e aos custos relacionados do projeto. 
 
Nível tático ou desenho lógico 
É a aplicação das decisões tomadas no nível estratégico. A 
solução contemplará a reutilização, ou não, de componentes, 
que serão desenvolvidos para ele, buscando satisfazer os 
requisitos do produto. 
 
Nível operacional ou desenho detalhado 
É o comportamento de cada componente. É desenvolvido em 
conjunto com a documentação voltada para usuários, no caso de 
desenho externo, ou documentação do código do programa, no 
caso de desenho interno. 
 
REUTILIZAÇÃO 
Nesta fase, é comum se fazer uso de processos que já foram definidos e utilizados em outras fases do produto ou 
sistema. 
 
ATENÇÃO: 
O processo de reutilização visa à redução do desperdício de tempo e, consequentemente, dinheiro, visto que, 
a cada iteração, os defeitos que existiam em outras fases já foram sanados. 
*NÍVEIS DE REUTILIZAÇÃO 
 
Código:Reutilização de parte de código de programa. 
Reutilização de Classe:Módulo de código binário. 
Desenho:Aproveitamento de ideias para solução de problemas encontrados no desenho é comumente baseado em 
classes abstratas derivadas por herança de outra classe. 
Reutilização de Plataforma: Camada de arquitetura 
Reutilização de objeto: Bibliotecas e classes fundamentais. 
 
DESENHO DO SOFTWARE 
• Fase: Desenho ou Design ou Projeto 
– Atenção aos requisitos  via modelos de análise 
– COMO a solução deve ser implementada 
– COMO FAZER – detalhes de funcionamento interno. 
• Fase que antecedeu o Projeto 
– Análise (O QUE Fazer) 
– Usar os modelos da analise (casos de uso, classe e sequência, no caso de análise OO usando UML) 
CONTEXTO 
• Aumento do tamanho e da complexidade do software 
• Pressão para: Redução do tempo e custo 
– Desenvolvimento 
– Manutenção 
Apelo ao Software green – TI verde 
VISÕES DO PROJETO 
• EXTERNA 
– Visão do usuário 
– Modelo de interação  interface 
• INTERNA 
– Componentes do sistema 
– Relação entre os componentes (acoplamento) 
– Funcionamento do componente 
– Interconexões com outros sistemas 
NÍVEIS DE DESENHO 
• ESTRATÉGICO 
– Modelo da Arquitetura. Forma do sistema. Partes e relacionamentos. Sistemas e sub-sistemas. 
• TÁTICO OU DESENHO LÓGICO 
– Decisões tomadas no nível estratégico 
– Reutilização ou não de componentes 
• OPERACIONAL OU DESENHO DETALHADO 
• Comportamento do componente 
ARQUITETURA do SW 
 1. Estruturação do sistema 
 Estruturado em subsistemas 
 Subsistema=unidade independente 
 Comunicação entre subsistemas 
 2. Modelagem de controle 
 Modelo de relacionamento entre as partes de um sistema 
 3. Decomposição modular 
 Cada subsistema é divido em módulos 
DECOMPOSIÇÃO EM MÓDULOS 
 Modelo orientado a objetos 
 Diagrama de classes 
 Diagrama de componente 
 Interação 
 Diagrama de sequencia. 
 Diagrama de Atividade 
DIAG CLASSES-Implementação ( vide figura na aula 3) 
DIAGRAMA DE COMPONENTES 
 Mostra os módulos do sistema 
 Esta relacionado a LP a usar 
 Determina como os componentes irão interagir. 
 Um componente representa um empacotamento físico de elementos relacionados logicamente 
(normalmente classes
 
 
META: REUTILIZAÇÃO 
 Idéia: usar o que já existe 
 Visa redução de tempo e R$ 
 Garante a segurança: componente usado e testado 
NÍVEIS DE REUTILIZAÇÃO (vide figura acima*) 
DEMAIS ATIVIDADES 
 Definições 
 Interface com usuário 
 Arquitetura de hardware e SO. 
 Linguagem de programação 
 Estrutura de rede e comunicações 
 SGBD – banco de dados 
 
 
 
 
 
 
 
 
Aula 5 
AS ATIVIDADES DE TESTE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
A fase de teste tem como objetivo detectar possíveis defeitos ou erros que possam surgir na fase de implementação. 
Nessa fase, de testes, deve-se coletar os resultados e analisá-los e consertá-los antes de sua implantação. 
 
Essa fase é essencial para aumentar a qualidade do produto ou sistema em que será implantado. 
 
Testes de Software 
Teste Objetivo Critério Procedimento “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 não 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 de testes. 
É uma 
representação 
definida de um 
procedimento teste. 
TESTE DE SISTEMAS: Análise e verificação de todos os componentes do sistema(hardware e software). Validar 
se estão em conformidade com os requisitos anteriormente definidos. Para uma melhor analise, o teste deve ser 
feito por uma equipe independente, diferente da equipe desenvolvedora. 
TESTE CAIXA PRETA:Teste que não leva em conta os mecanismos e definições internos do sistema. O objetivo 
principal está no resultado da saída de dados do sistema, mediante a entrada definida de dados. 
TESTE CAIXA BRANCA:Teste que leva em conta a sua estrutura interna de construção. Os mecanismos internos do 
sistema serão analisados e suas representações lógicas também. O teste da caixa branca não exclui a necessidade 
do teste da caixa preta, uma vez que o funcionamento interno do sistemaou produto pode ser aceito logicamente, 
embora possa resultar em uma saída diferente da esperada. 
Modalidade dos testes 
 Quanto à utilização do código 
Testes estáticos: São testes realizados pela análise do código fonte. O tipo de análise é visual, podendo haver um 
questionário para acompanhar os testes, inspecionando o código desenvolvido pela equipe de programação. 
Testes dinâmicos:São testes baseados na execução do código do programa. Os testes seguem, também, um 
questionário com base nos aspectos estruturais e funcionais do programa. 
 Quanto ao objetivo na busca pelo erro 
Testes de unidade: Teste realizado em um módulo ou em alguns módulos definidos que representam uma única 
unidade. A determinação da quantidade de módulos a serem testados está contida na documentação de projeto. 
Testes de integração:Teste para identificar erros durante a integração e interação entre os módulos ou unidades do 
sistema. 
Testes de validação:Teste realizado após a integração de todos os módulos do sistema. 
AS FASES DO PROCESSO 
 
O CICLO DE VIDA 
 
1ª. DEFINIÇÃO DE TESTE 
• A fase de teste tem como objetivo detectar possíveis defeitos ou erros que possam surgir NA da fase de 
implementação. 
• Nessa fase, DE TESTES deve-se coletar os resultados e analisá-los E CONSERTÁ-LOS antes de sua 
implantação. 
• Fase fundamental, muitas vezes relegada a segundo plano ou mesmo esquecida Incremento na 
QUALIDADE, na medida em que avaliamos sob várias óticas. 
 
FASE: TESTES 
• Objetivo: encontrar erros não descobertos 
– Bem sucedido: Acha erro não previsto 
– É preciso usar 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 analise, o teste deve ser feito por uma equipe independente, diferente da equipe 
desenvolvedora. 
MODALIDADES DE TESTES 
• Classificação quanto ao uso do código 
– Testes estáticos ou Verificações 
• ANTES da implementação 
• Inspeções, revisões, auditorias 
• Testes nas 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 encarnado 
• Qualidade no produto 
 
• Classificação quanto objetivo 
– Teste de Unidade (programação) 
• Em Unidades de programas. 
• Busca de Erros nos programas individuais 
– Teste de Integração (prog / testes) 
• Identificar 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 
ESTRATÉGIAS DE TESTES 
• TESTE DA CAIXA PRETA (+ simples) 
– Não considera a forma como esta implementado – detalhes internos 
– Objetivo: 
• o sw produz os resultados esperados? 
• Os requisitos estão sendo atendidos? 
– Vantagem: não requer conhecimento técnico da tecnologia empregada ou da implementação 
aplicada  requer profissional menos capacitado. 
• TESTE DA CAIXA BRANCA (+ Complexos) 
– Baseados na arquitetura interna do software. 
• Verificação de código 
– Objetivo: identificar defeitos nas estruturas internas do sw, através da simulação que “testem” toda a 
estrutura usada na codificação 
– Desvantagem: requer conhecimento técnico da tecnologia empregada pelo software e arquitetura 
interna da solução  requer profissional BEM capacitado.  Difíceis de serem implementados. 
– Vantagem: eficientes na detecção de erros. 
• Casos de testes que cubram TODAS possibilidades 
TESTE DE UNIDADE 
 1ª. Etapa do processo de validação. 
 Testa UMA unidade: modulo/classe 
 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 testes da caixa preta 
TESTE DE INTEGRAÇÃO 
 Natural continuidade dos testes de Integração 
 Verificar a compatibilidade da nova unidade com as demais, já prontas. 
 Verificar se Juntas e integradas, as unidades funcionam 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. 
TESTES DE SISTEMAS (VALIDAÇÃO) 
 Homologação: interna e externa 
 Ú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 sistema completo. 
 Reduz o risco da entrega 
TESTES DE ACEITE 
 Homologação: interna e externa 
 Ú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 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 
 
 
 
 
 
 
 
 
 
 
 
Avaliação Parcial 
 
 
AULA 6 
A IMPLEMENTAÇÃO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
A fase de implementação, ou codificação, tem como objetivo escrever o programa em uma linguagem de 
programação, seguindo normas e diretrizes da empresa à qual o desenvolvedor esteja ligado. 
 
Na fase da implementação, o analista ou desenvolvedor detalha e implementa o que foi definido na etapa de 
desenho, através de componentes de código de programa e documentação detalhada. 
Definições 
IMPLEMENTAÇÃO DESENHO 
Processo que realiza a 
transformação do desenho em 
diversos tipos de componentes de 
código de programação. 
Etapa do processo de 
desenvolvimento de software já 
estudada anteriormente. 
O código de programação pode ser dividido em 3 tipos: 
CÓDIGO FONTE: Conjunto de instruções geradas através de uma linguagem de programação, de maneira lógica e 
estruturada; após o processo de compilação ou interpretação, transformar-se-á em código objeto. 
CÓDIGO OBJETO: Resultado da compilação do CÓDIGO FONTE. 
CÓDIGO MÁQUINA: Sequência binária de ações diretamente direcionadas para o processador da máquina. 
 
COMPILADOR INTERPRETADOR LINGUAGEM DE BAIXO 
NÍVEL 
LINGUAGEM DE ALTO 
NÍVEL 
Programa que faz uma 
leitura do código fonte, 
desenvolvido em uma 
linguagem de alto nível, e 
transcreve para um novo 
Programa que, além de 
fazer a leitura do código 
fonte e transformá-lo em 
código objeto, transforma-
Linguagem de 
programação que utiliza a 
arquitetura do processador 
para executar as ações . 
Esta linguagem é a que 
Comumente chamada de 
linguagem de 
programação, esta 
linguagem se aproxima 
mais da linguagem 
tipo de linguagem 
chamada de baixo nível. 
o em um código 
executável. 
mais se aproxima dos 
códigos de execução 
direta do processador, ou 
seja, linguagem de 
máquina. 
humana, ou seja, 
linguagem com um padrão 
de entendimento humano 
bem definido. Para essa 
linguagem não é levado 
em consideração a 
arquitetura do 
computador, nem as 
características do 
processador e seus 
registradores, visto que, 
na fase de interpretação 
ou compilação, esses 
programas transformarão 
em linguagem de baixo 
nível ou de máquina. 
 
Classificações das linguagens 
LINGUAGEM DE PRIMEIRA GERAÇÃO 
Desenvolvida no inicio da era dos computadores, esta linguagem é interpretada pelos microprocessadores. Cada 
microprocessador possui uma linguagem própria de entendimento, o que pode ocasionar erros de programação 
em processadores de uma mesma família de fabricantes. 
Ex: Assembly. 
 
LINGUAGEM DE SEGUNDA GERAÇÃO LINGUAGEM DETERCEIRA GERAÇÃO 
Surgida em meados dos anos 50, foi considerada 
a primeira linguagem de alto nível, visto que era 
de fácil entendimento e, portanto, considerada 
mais humana. Ex: COBOL, Pascal, FORTRAN. 
 Em meados dos anos 80, surgiram o conceito 
de programação estruturada e a programação orientada a 
objeto. 
 
LINGUAGEM DE QUARTA GERAÇÃO 
É característica dessa lniguagem dar suporte para execução de rotinas auxiliares a linguagens de terceira geração. 
Ex: Linguagem de consulta, utilizada para conexão com banco de dados. 
Documentação 
Uma vez que o desenho será a base da implementação, o processo de documentação de uso do produto passa a ter 
importância nesta fase, onde a documentação e a programação devem andar lado a lado. 
 
IMPLEMENTAÇÃO 
A fase de implementação, ou codificação, tem como objetivo escrever o programa em uma linguagem de 
programação, seguindo normas e diretrizes da empresa à qual o desenvolvedor esteja ligado (metodologia = 
qualidade no processo) 
 
 As empresas costumam definir padrões para o desenvolvimento. 
Na fase da implementação, o programador: 
detalha e implementa o que foi definido na etapa de desenho, através de componentes de código de programa e 
documentação detalhada. 
IMPLEMENTAÇÃO DESENHO 
Etapa do processo de 
desenvolvimento que realiza a 
transformação do desenho em 
diversos tipos de componentes 
de código de programação 
Etapa do processo de 
desenvolvimento em que foi 
definida a arquitetura do 
sistema e definida a tecnologia 
usada na implementação 
COMPONENTES DE CÓDIGO 
Código Fonte: Conjunto de instruções gerados através de uma L.P., de forma lógica e estruturada (L.P de alto nível) 
Código Objeto: Resultado da compilação do código fonte 
Código de máquina: Sequência binária de instruções, que são executadas diretamente por um processador 
(conjunto específico de instruções). 
Linguagem de baixo nível 
Utiliza a arquitetura do processador 
 
LINGUAGEM DE MÁQUINA 
O Hardware é composto de componentes eletrônicos, onde passa ou não corrente. 
A ausência ou não de corrente, cria para o hardware uma linguagem de apenas 2 símbolos: 0 (zero) e 1 (um). 
É a chamada linguagem binária (Bi = dois) ou linguagem de máquina. 
0000011000100000 – seria um comando (instrução) para um processador de 16 bits de tamanho de palavra. 
LINGUAGEM ASSEMBLY 
 Trocou-se 0 e 1, por mneumônicos 
 Ao invés de endereçar posições físicas de memória, usou Registradores 
 ADD R1, R2, R3 ([R3]=[R1]+[R2]) 
 Surge o Montador 
 
LINGUAGEM DE ALTO NÍVEL 
 Linguagem que se aproxima da linguagem humana 
 Não leva em consideração a arquitetura do computador, nem as características do processador e seus 
registradores. 
 
COMPARAÇÃO LINGUAGENS 
 
COMO CONVERTER ? 
 
 2 processos fazem esse papel 
o Interpretação (Interpretador) 
 TRADUZ O CÓDIGO A MEDIDA QUE EXECUTA 
 Python, Pearl, PHP, Javascript, ASP 
o Compilação (Compilador) 
 TRADUZ E DEPOIS EXECUTA 
 C++, 
INTERPRETAÇÃO 
o Interpretação é a "tradução" do código em linguagem de máquina em tempo de execução. 
o É utilizada: PHP, ASP, Javascript. 
o Uma característica marcante das linguagens interpretadas são que elas executam o código até o ponto em 
que há um erro. 
o Por acontecer em tempo de execução,tipicamente tem um desempenho um pouco menor. 
 
COMPILAÇÃO 
o Primeiro, faz uma leitura completa do código, identificando variáveis e outros elementos e montando uma 
tabela com estas informações. 
o No segundo passo, a "tradução" do código em linguagem de máquina. Entretanto, a compilação difere da 
tradução porque ela faz alterações no código, de forma a torná-lo otimizado. 
o Enquanto uma linha é sempre uma instrução na tradução, x linhas no código terão y linhas de comandos 
de máquina, de acordo com o compilador. 
o Compiladores modernos conseguem enormes otimizações em certos códigos. 
COMPILADOR / HÍBRIDO 
AMBIENTES DESENVOLVIMENTO 
 
 
 
 
 
 
JAVA 
 
 
BOA PRÁTICA- PROGRAMAÇÃO 
 Documentar com comentários o código fonte 
o // este procedimento visa calcular o digito verificar com base no modulo 11 
o // Data: Autor: Data alteração: 
 Bons nomes – auto-explicativos e padronizados 
o variável: NA ?? 
o Variável: nome_aluno 
PROG. BASEADA EM COMPONENTES 
 Um componente é uma unidade reutilizável de software, tipicamente, com fronteiras bem definidas e 
encapsulado 
o Independente 
o Programação: componentes = classe 
 Ganho de escala  reaproveitamento 
 Mais segurança 
 Mais agilidade 
 Sistema = conjunto de componentes 
PROGRAMAÇÃO EM PAR 
 Técnica usada nas metodologias ágeis 
 2 programadores trabalham juntos 
 Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas 
juntas, diante do mesmo computador, revezando-se no teclado. 
 1 faz (executor) e outro verifica (observador) / alternam-se nas tarefas 
 A programação em par é uma forma eficaz de reduzir a incidência de bugs em um sistema. 
 Isso se deve em grande parte às visões complementares que atuam durante o uso dessa prática. 
 Quando dois desenvolvedores estão programando em par, um deles está com as mãos no teclado e no 
mouse. O outro está sentado ao lado, olhando para a mesma tela e preocupado em resolver o mesmo 
problema. Ambos estão trabalhando juntos na solução, embora apenas um esteja com as mãos no teclado. 
Eles conversam o tempo todo e trocam idéias sobre a solução. 
 A programação em par explora a diversidade de idéias que é rara de ser observada quando se programa 
sozinho – troca de conhecimento 
 A programação em par também é uma forma de fazer com que o desenvolvedor tenha mais confiança no 
código que produz, reduzindo seu stress 
 Treinamento de programadores sem experiência. 
 
 
 
 
Aula7 
A DOCUMENTAÇÃO DO SISTEMA DE SOFTWARE 
Nesta aula iremos definir o conceito de manutenção para o processo de desenvolvimento de software. 
A fase de manutenção, tem como objetivo corrigir os erros que não foram detectados nas fases anteriores, propor 
melhorias no sistema e prover suporte do sistema que foi desenvolvido. 
Nessa fase, é fundamental o acompanhamento do produto desenvolvido, para o suporte e o processo de 
manutenção, entrando assim em uma nova fase de analise de requisito, ou seja, a fase inicial do processo de 
desenvolvimento de software. 
Documentação do produto 
Processo que adota métodos e formatos padronizados para cada família de produtos correlatos. 
Manual do usuário Manual de introdução Manual de referência 
Documento com formato adequado 
ao perfil do publico que utilizará o 
sistema ou produto. A linguagem 
deve se clara e os termos e 
construções devem estar de acordo 
com o nível cultural e técnico do 
usuário final. 
Descreve as funcionalidades do 
sistema, como o usuário pode 
utilizar, os pré-requisitos 
necessários para funcionar. 
Descreve facilidades do uso do 
sistema, informa os erros que 
podem ocorrer e como agir quando 
encontrá-los. 
 
Documento de instalação Referência rápida Documentação do software 
Descrição de como instalar o 
sistema, plataformas de operação, 
pré-requisitos necessários. 
Documento com um resumo das 
funcionalidades, atalhos de 
procedimentos, principais funções 
utilizadas, e mensagens de erros 
mais comuns. 
 
 
Uma referência básica para o 
padrão manual é o IEE Std. 1063-
2001 
Processo que descreve as partes do 
código fonte, requisitos necessários, 
arquitetura do sistema. Essa 
documentação é bastante útil para o 
desenvolvedor no processo de 
melhoria ou correção do produto. 
 
Manutençãodo software Refatoração Separação estática 
Consiste em corrigir defeitos ou 
deficiências encontradas pelos 
administradores ou usuários do 
produto. A manutenção também 
pode ser considerada um processo 
de melhoria das funcionalidades do 
software. 
Dentro do processo de manutenção 
do software existe a refatoração, 
que tem como objetivo melhorar um 
sistema de software, modificando 
sua estrutura interna, sem alterar o 
comportamento interno. 
Processo pelo qual identifica-se 
variáveis que apresentem algum tipo 
de não conformidade com o 
programa. O processo leva a 
identificação do código onde a 
variável afeta sua funcionalidade. 
 
Documentação do processo 
Cronogramas Relatórios Padronização de 
processos 
Comunicação Documentos 
técnicos 
Documentação 
utilizada por 
gerentes de 
projetos, executivos 
e gerentes 
funcionais, para 
acompanhar o 
andamento do 
projeto. 
Documentação de 
acompanhamento de 
recursos utilizados 
durante o 
andamento do 
projeto. 
Estabelece o 
formato e a cadência 
de como o processo 
deve ser 
implementado. Essa 
padronização pode 
seguir o formato 
definido pela 
empresa, 
organização, ou um 
formato mais 
abrangente, como 
nacional ou 
internacional. 
Estabelece a forma 
de comunicação 
entre os membros 
do projeto. 
Descreve 
estratégias de como 
chegar ao resultado 
final, registram os 
erros, problemas e 
ideias que ocorrem 
durante o projeto, e 
as razões que foram 
utilizadas para as 
tomadas de 
decisões. 
 
MANUTENÇÃO 
 Fase que tem: 
 Início: quando o sistema é instalado no ambiente do usuário, para uso. 
 Fim: quando o sistema torna-se obsoleto e é substituído. 
 Motivos da obsolescência: 
 Tecnologia ultrapassada 
 Custo de manutenção supera benefícios 
 Ciclo de Vida do Sistema = Ciclo de desenvolvimento + Manutenção 
 Logo 
o Quanto maior o tempo da fase de manutenção, maior a vida útil do sistema 
 A qualidade da manutenção vai depender da qualidade no processo de desenvolvimento 
o Documentação atualizada e adequada 
o Código eficiente e bem documentado 
 Desafio: manter documentação atualizada, na medida em que são feitas alterações no sistema. 
ATIVIDADES DA MANUTENÇÃO 
 Suporte ao uso do sistema 
o Manuais, Help desk, visitas, treinamento 
 Desenvolvimento 
o Correção de erros (início)  ausência ou má qualidade dos testes 
o Melhorias nas funções existentes 
o Implementação de novas funções 
 Melhorias nas funções existentes 
o Comum: efeito dominó  arquitetura inadequada 
o Soluções 
 Separação estática: identificar foco 
 Refatoração: modificação da estrutura do software, sem alterar o comportamento. 
AFETAM O CUSTO DA MANUTENÇÃO 
 Tipo de Aplicação 
 Rotatividade e disponibilidade-Pessoal 
 Duração da vida útil do sistema 
 Ambiente (em que o sistema está inserido) que se modifica 
 Características do hardware 
 Qualidade do projeto, do código, da documentação e dos testes 
 Caracteristicas das L.P. usadas 
 O tempo da manutenção define o tempo de vida. 
 Atentar para o custo. 
 Elementos altamente coesos 
 Elementos com baixo acoplamento 
 Documentação completa e atualizada 
MANUTENÇÃO COMO PROJETO 
 Cuidado com as novas versões 
o Causam instabilidade no ambiente 
o Ideal: 
 menos intervenção possível 
 acumular demandas que justifiquem a intervenção 
 tratar as demandas como um projeto 
o Dificuldade: controle das versões. 
COMO ACUMULAR DEMANDAS 
 Documento de demandas dos usuários 
o Data, Pedido, Tipo 
o Tipo 
 emergencial (imediato) 
 melhoria e nova função (analisar) 
DOCUMENTAÇÃO PARA SUPORTE 
 Manual do usuário 
o Linguagem clara e adequado ao perfil 
o Mostrar como o usuário usa as funcionalidades 
 Manual de Introdução 
o Descreve as funcionalidades do sistema, sob a ótica do uso (uso) 
o Os pré requisitos necessários para operar 
 Manual de Referência 
o Descreve as facilidades do uso do sistema 
o Informa os erros que podem ocorrer e como agir quando entregá-los. 
 Documento de Instalação 
o Descrição de como instalar o programa 
o Plataforma de operação 
o Pré-requisitos necessários 
 Referência básica 
o Documento com um resumo das funcionalidades, atalhos de procedimentos, principais funções 
utilizadas, e mensagens de erros mais comuns. 
 Documentação do software 
o Processo que descreve as partes do código fonte, requisitos necessários, arquitetura do sistema. 
Essa documentação é bastante útil para o desenvolvedor no processo de melhoria ou correção do 
produto. 
 Manual do Sistema 
o Referência 
 Facilidades do uso do sistema 
 Erros que podem ocorrer e como agir 
o Instalação 
 como instalar o sistema, plataformas de operação, pré-requisitos necessários. 
DOCUMENTAÇÃO PARA MANUTENÇÃO 
 Possibilitar que a equipe entenda o que foi pensado e as soluções dadas. 
 Possibilitar que as alterações e novas funções possam ser documentadas. 
 Tipo de documentação: textual e modelos (diagramas). 
 Ferramenta CASE ajuda a manter a documentação VIVA e atualizada. 
 Documentação do software 
o Descreve as partes do código fonte, requisitos necessários, arquitetura do sistema. 
o Bastante útil para o desenvolvedor no processo de melhoria ou correção do produto. 
DOCUMENTAÇÃO DO PROCESSO 
 Cronogramas 
o Acompanhar o andamento 
 Relatórios 
o Documentar acompanhamento de recursos 
 Padronização de processos 
o Da empresa 
o Ou referencia nacional / internacional 
 Comunicação entre projetos. 
 Documentos técnicos 
o Descreve estratégias de como chegar ao resultado final. 
o Registram erros, problemas e idéias que ocorrem durante o projeto 
o As razões para tomar decisão 
 
 
Aula 8 
O DESENVOLVIMENTO DO SOFTWARE EM CASCATA 
Inicialmente, não se seguia um modelo de desenvolvimento de software. Os desenvolvedores baseavam-se em suas 
próprias experiências e não havia uma forma definida e estruturada para o desenvolvimento. O resultado era softwares 
que entravam em produção com erros não testados e com a obrigatoriedade de correções após a fase de 
implementação. 
O modelo em cascata, também conhecido como “water fall” ou “Top-Down” tem como característica utilizar as etapas, 
que foram estudadas anteriormente, de um modo sequencial e constantemente para frente. 
Modelo inicial 
Modelo balbúrdiaMetodologia de desenvolvimento de software em que os antigos desenvolvedores baseavam-se 
em suas próprias experiências para desenvolver os softwares. 
Esse modelo podia ser descrito por um ciclo de 2 fases: 
 IMPLEMENTAÇÃO 
 CORREÇÃO 
Codifica-remendaMetodologia semelhante ao modelo balbúrdia em que, após a implementação, os erros e 
atualizações eram descobertos durante a sua utilização. Os ajuste que precisavam ser feitos eram programados em 
caráter de urgência, gerando insatisfação e pressões de usuário. 
Como consequência, a qualidade e a confiabilidade do sistema eram sempre postos à prova. 
Modelo cascata 
Ciclo de vida do projetoConjunto de atividades descritas e ordenadas que segue um fluxo contínuo de informações 
e relacionamentos para auxiliar o acompanhamento de um projeto. 
Modelo de processo cascataPrimeiro modelo conhecido em engenharia de software. Consiste em um modelo linear 
em que cada atividade tem de ser completada antes de iniciar a próxima. 
EXEMPLO 
Abaixo. A etapa de Projeto só poderá ser iniciada após a finalização da etapa de requisitos. 
 
Vantagens do modelo cascataPara pequenos projetos que não necessitem de padronizações e documentações, o 
modelo em cascata pode ser útil, pois o ganho de tempo na fase de planejamento pode ser um diferencial no tempo 
total do projeto.Desvantagens do modelo cascataO modelo em cascata visa ao encerramento de uma fase, ou etapa, para o início 
da outra subsequente. Durante um projeto, algumas atividades estão em constante mudança, uma delas são os 
próprios requisitos. Se o processo somente pode ser seguido após a finalização da etapa anterior, este nunca irá se 
encerrar. 
Modelo em cascata com realimentação 
Modelo em cascata com realimentaçãoModelo que permite a revisão de fases anteriores e a superposição entre as 
fases. Esse modelo é uma variante do modelo cascata tradicional que permite a realimentação, ou seja, correções que 
surgirem durante outras fases do processo. 
Exemplo.: 
 
Vantagens do modelo cascata com realimentaçãoPossibilidade de correção de erros durante o processo de 
desenvolvimento de software. 
Desvantagens do modelo cascata com realimentaçãoDependendo da quantidade de revisões e realimentações, o 
processo pode se tornar difícil de gerenciar. 
Anos: 70/80 
 Antes: Não era usado processo de desenvolvimento. 
 Programadores baseavam-se nas próprias experiências. 
 Não havia forma definida e estruturada. 
 Não haviam testes e os erros eram corrigidos após implantação. 
 
MODELOS INICIAIS 
Modelo Balburdia 
Base: experiência dos programadores 
2 fases: Implementação & Correção 
Modelo Codifica-remenda 
 Erros descobertos com o uso 
o Ajustes em caráter de urgência 
 Insatisfação e pressão dos usuários 
 Surge a idéia de necessidades após implantação, pois os sistemas tornavam-se maiores. 
 Confiabilidade e qualidade começam a ser contestadas 
MODELO CASCATA 
 Ciclo de Vida do projeto 
o Atividades ordenadas, com fluxo contínuo para auxiliar o acompanhamento do projeto. 
 Atividades 
 Fluxo de informações 
 Relacionamento entre atividades 
 1º. Modelo em Engenharia de Software 
 Linear  a atividade é concluída antes de iniciar a próxima. 
o Sequencial e “para frente” 
 
 Útil: pequenos projetos 
o Sem padronização e documentação 
o Ganho na fase de planejamento. 
 Problema: 
o Durante o projeto, a fase de requisitos, está em constante evolução e mudança. 
 
 Vantagem 
o Permite pontos de controle bem definidos  facilita gestão do projeto 
o Requer documentação todas as fases. 
o Em tese  só avança se cliente Valida fase atual  Participação do usuário (primeira tentativa de 
aproximar) 
o Simples de implementar e gerir. 
MODELO CASCATA – DESVANTAGENS 
 Todos os requisitos devem ser descobertos no início  não prevê alteração 
 Não é possível corrigir erros em fases já completas. 
 Projeto raramente segue fluxo seqüencial  iterações (vários ciclos) são necessárias. 
 Não prevê manutenção. 
 Usuário só vê os resultados ao final (péssimo) 
 Dificulta visão de reutilização. 
 Se ocorrer atraso, todo processo é afetado; 
 Só gestor tem visão do todo. 
CASCATA C/RETROALIMENTAÇÃO 
 Variante “cascata tradicional” que permite a realimentação 
 Modelo que permite a revisão de fases anteriores e a superposição entre as fases. 
 Correções que surgirem durante outras fases do processo. 
 Porem o custo dessa revisão pode ser alto, dependendo da fase atual e do quanto se precisa retroceder. 
 
 Vantagem 
o Possibilita a correção de erros nas fase(s) anterior(es), durante o processo de desenvolvimento. 
o Prevê manutenção 
 Desvantagem 
o Dependendo da quantidade de revisões e realimentações, o processo pode se tornar difícil de 
gerenciar. 
 
Aula 9 
O PROCESSO ITERATIVO E INCREMENTAL 
Como vimos anteriormente, o modelo em cascata, também conhecido como “water fall” ou “Top-Down”, tem como 
característica utilizar as etapas que foram estudadas anteriormente de um modo sequencial e constantemente para 
frente, mas o processo em si possui algumas características, como: 
 - Passa para a fase subsequente somente quando a fase atual estiver completa. 
 - Não ser possível corrigir erros em fases já completas. 
 - O resultado do software somente será conhecido no final de todo o processo. 
Para resolver algumas dessas características, foi criada uma variante do processo com retro alimentação, ou seja, a 
possibilidade de corrigir e voltar em etapas anteriores. 
No processo iterativo e incremental, essas ideias e correções são feitas em pequenas porções ao invés do processo 
como um todo. 
Modelo iterativo 
Processo iterativo: Modelo que se baseia na ideia de melhoramento ou refinamento aos poucos. 
Caracteriza-se pela seleção de uma parte do projeto onde o grupo de desenvolvedores identifica, especifica, 
implementa e testa a iteração. Se esta atender às especificações, a equipe passa para a próxima iteração 
. 
Modelo Incremental: Modelo que se baseia na ideia de aumento do âmbito do sistema, ou seja, na criação de novas 
versões para o modelo proposto. 
 
Modelo Iterativo e Incremental: Metodologia de desenvolvimento de software que define um subconjunto de 
requisitos e utiliza o modelo em cascata para sua realização. 
Cada porção do ciclo segue o projeto de arquitetura inicial como guia, mas com uma abordagem bem menor. Uma vez 
satisfeitos os requisitos e os objetivos da iteração forem completos, o desenvolvimento segue para a próxima iteração. 
EXEMPLO 
 
MODELO ESPIRAL 
Prototipação 
Criação de um modelo para ser analisado e desenvolvido a partir dele. O Analista coletará informações (REQUISITOS) 
para um mini projeto (PROTÓTIPO), concentrando-se nas entradas e saídas do software, bem como em suas iterações 
entre usuário e programa. Após a criação e aceitação do protótipo, o produto final será desenvolvido. 
 
O Modelo espiral se assemelha com o propotipação, mas inclui um fator: a análise de risco. Funciona de forma iterativa, 
incremental, mas com uma etapa onde pode ser tomada a decisão de se interromper ou não o processo. 
 
PROCESSO ITERATIVO 
 Seleção de uma parte do projeto 
o Identifica, especifica, implementa, testa e implanta a iteração 
o Se atender as especificações, passa-se a próxima iteração. 
PROCESSO INCREMENTAL 
 Modelo que se baseia na idéia de aumento do âmbito do sistema. 
 Desenvolvimento em partes 
o Ou seja, na criação de novas versões para o modelo proposto. 
 As partes podem ser desenvolvidas em paralelo e integradas quando completas. 
MODELO ITERATIVO E INCREMENTAL 
 Processo de desenvolvimento de software que define: 
o um subconjunto de requisitos e 
o utiliza o modelo em cascata para sua realização. 
 Cada porção do ciclo segue o projeto de arquitetura inicial como guia, mas com uma abordagem bem menor. 
 Uma vez satisfeitos os requisitos e os objetivos da iteração forem completos, o desenvolvimento segue para a 
próxima iteração. 
 Os passos fundamentais são: 
o iniciar o desenvolvimento com um subconjunto simples de Requisitos de Software e 
o iterativamente alcançar evoluções subseqüentes das versões até o sistema todo estar implementado. 
o A cada iteração, as modificações de projeto são feitas e novas funcionalidades são adicionadas 
MODELO: PROTOTIPAÇÃO 
 Criação de um modelo para ser analisado e desenvolvido a partir do protótipo 
 O Analista coletará informações para um mini projeto, concentrando-se nas entradas e saídas do software. 
 Após a criação e aceitação do protótipo, o produto final será desenvolvido. 
 O protótipo serve como mecanismo para identificar os requisitos. 
 Tipos de protótipo: 
o em papel ou sistema: retratam a interface e interação 
o em sistema, implementando algumas funções 
 Quando usar? 
o O cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de 
entrada, processamento e saída com detalhes 
o O desenvolvedor não tem certeza da eficiência de um algoritmo ou forma da interação. 
 1- OBTENÇÃO DOS REQUISITOS 
o O desenvolvedor e o clientedefinem os objetivos gerais do software, identificam quais requisitos são 
conhecidos e as áreas que necessitam de definições adicionais. 
 2- PROJETO RÁPIDO 
o É a representação dos aspectos do software que são visíveis ao usuário (entrada e formatos de saída). 
 3- CONSTRUÇÃO PROTÓTIPO 
o É a implementação do projeto rápido. Serve como o “primeiro sistema” - recomendado que não seja 
usado como produto final. 
 4- AVALIAÇÃO DO PROTÓTIPO 
o Cliente e desenvolvedor avaliam o protótipo. 
 5- REFINAMENTO DOS REQUISITOS: 
o Com base na avaliação, refinam o produto 
o Ocorre neste ponto um processo de iteração que pode conduzir à atividade 1 até que as necessidades 
do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito. 
 6- CONSTRUÇÃO PRODUTO: 
o A versão de produção deve ser construída considerando os critérios de qualidade. 
o Protótipo deve ser descartado 
MODELO: ESPIRAL 
O Modelo espiral se assemelha com o propotipação, mas inclui um fator: a análise de risco. 
Funciona de forma iterativa, incremental, mas com uma etapa onde pode ser tomada a decisão de se interromper ou 
não o processo. 
 
 Cada volta da espiral representa uma fase do processo: 
 Planejamento: Definição os objetivos, alternativas 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: Avaliação dos resultados 
 Não há fases fixas como especificação e desenho - as voltas na espiral são determinadas pelo que é requerido. 
 Riscos são explicitamente avaliados e resolvidos no processo 
 Engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo 
elemento: a ANÁLISE DOS RISCOS. 
 Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos. 
 
 Vantagens 
o Modelo evolutivo, possibilita uma maior integração entre as fases e facilita a depuração e a 
manutenção do sistema. 
o Permite que o projetista e cliente possam entender e reagir aos riscos em cada etapa evolutiva. 
 Desvantagens 
o Avaliação dos riscos exige muita experiência. 
o O modelo é relativamente novo e não tem sido amplamente utilizado. 
 
 
 
MODELO VANTAGENS DESVANTAGENS 
CASCATA 
• Minimiza o tempo de planejamento 
• Funciona com equipes 
tecnicamente fracas 
• Inflexível 
• Documentação é fundamental 
• Difícil voltar atras para correção de 
erros 
 
ESPIRAL 
• As interações inicias do projeto são 
as mais baratas, permitindo que as 
tarefas de maior risco tenham custo 
baixo. 
• Cada iteração da espiral pode ser 
customizada para as necessidades 
específicas de cada projecto. 
• É complexo e requer atenção e 
conhecimento especiais para sua 
implementação 
PROTOTIPAÇÃO 
• Os clientes conseguem ver os 
progressos. 
• É útil quando os requisitos mudam 
rapidamente e o cliente está 
relutante em aceitar um conjunto de 
requisitos. 
• É impossível determinar com exatidão 
o tempo que o projeto vai demorar. 
• Não há forma de saber o número de 
iterações que serão necessárias. 
 
 
 
 
 
 
AULA 10 
OS OUTROS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 
Como vimos anteriormente, os modelos seguiam um padrão de organização onde se criavam etapas ou módulos 
caracterizados pelas ações que se tomariam durante um período determinado. Esses períodos se caracterizavam por 
fases que, após serem finalizadas, davam inicio a uma outra fase, com características diferentes. 
Cada fase representava uma ação que possuía um inicio e um fim, mesmo nos casos de realimentação. 
Para os modelos aqui apresentados, não estão somente levados em conta o planejamento e ação, mas também os 
valores e os recursos envolvidos. 
Processo de desenvolvimento Ágil 
METODO ÁGIL: É um conjunto de diretrizes e metodologias que cria uma estrutura conceitual para desenvolver 
projetos de desenvolvimento de software. 
Baseado em um manifesto criado por programadores veteranos que já tinham passado por inúmeras experiências 
diferentes no campo de desenvolvimento de software, o Manifesto Ágil tem como foco as pessoas e não as ferramentas. 
Manifesto para Desenvolvimento Ágil de Software 
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a 
fazerem o mesmo. Através deste trabalho, passamos a valorizar : 
 Indivíduos e interações mais que processos e ferramentas. 
 Software em funcionamento mais que documentação abrangente. 
 Colaboração com o cliente mais que negociação de contratos. 
 Responder a mudanças mais que seguir um plano. 
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. 
Princípios por trás do Manifesto Ágil 
Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada 
de software com valor agregado. 
Mudanças nos requisitos são bem-vindas,mesmo tardiamente no desenvolvimento. 
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 
Entregar frequentemente software funcionando,de poucas semanas a poucos meses,com preferência à menor escala 
de tempo. 
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário 
e confie neles para fazer o trabalho. 
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de 
conversa face a face. 
Software funcionando é a medida primária de progresso.Os processos ágeis promovem desenvolvimento sustentável. 
Os patrocinadores, desenvolvedores eu usuários devem ser capazes de manter um ritmo constante indefinidamente. 
Contínua atenção à excelência técnica e bom design aumenta a agilidade. 
Simplicidade a arte de maximizar a quantidade de trabalho não realizado é essencial. 
As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis. 
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento 
de acordo. 
METODO XP: Também conhecido como eXtreme Programming, é um método (O modelo propõem uma série de 
práticas focados em pessoas, ou seja, na equipe de desenvolvimento.) que pertence à metodologia ágil de 
desenvolvimento de software. 
 É baseado em 5 valores: 
 COMUNICAÇÃO 
 CORAGEM 
 FEEDBACK 
 RESPEITO 
 SIMPLICIDADE 
Algumas Práticas do método XP 
– Reuniões em pé: Utilizadas para não perder o foco no assunto. 
– Programações em par Formada por uma dupla no papel de iniciante e de instrutor, Como utilizam um único 
computador, o código passa automaticamente pelo crivo de duas pessoas. 
– Testes de aceitação Testes com validação do cliente. 
– Posse coletiva O código fonte não pertence a ninguém, é de todos e todos podem utilizá-lo sem necessidade 
de permissão. 
– Pequenas versões Pequenas versões aceitas pelo cliente ajudam na aceitação do programa completo. 
– Ritmo sustentável Utilizar o tempo de trabalho dentro do especificado. Sem horas adicionais. (40 horas por 
semana) 
– Padrão de codificação Estabelecimento de regras de código de programa. 
METODO SCRUM: Metodologia que tem como filosofia o Manifesto Ágil. 
Possui papel bem definido para as atividades durante todo o processo. Uma vez levantadas as questões a serem 
trabalhadas, é determinado um período de tempo para a realização de um determinado requisito. 
Durante esse intervalo, são feitas reuniões diárias para acompanhamento do andamento das atividades. 
 
Características do modelo Scrum 
– Product Backlog Lista de itens que o cliente deseja que sejam implementados.– Sprint Backlog Análise feita do Product Backlog. Cada requisito é analisado, interpretado e informado à 
equipe como será implementado. 
– Sprint Período definido para cada finalização de requisito. 
– Scrum Reunião diária para análise de andamento do projeto. 
– Scrum Máster Responsável por coordenar o Scrum e ajudar a atender os impedimentos que possam 
ocorrer na tentativa de não estourar o Sprint. 
Processo unificado 
RUP: Também conhecido como Rational Unified Process, é um processo que faz parte da engenharia de software. Ele 
é baseado em disciplinas em que cada uma distribui tarefas e responsabilidades para os envolvidos no 
desenvolvimento do software. 
Essas disciplinas são semelhantes às que estudamos anteriormente: 
• Modelagem de negócios 
• Requisitos 
• Análise e design 
• Implementação 
• Teste 
• Implantação 
Ainda no RUP, existem 3 disciplinas que servem de suporte e apoio ao ambiente: 
– Configuração e mudanças Acompanham mudanças, configurações e status/medições onde são 
armazenados e que servirão de base para o andamento do projeto. 
– Projeto Abrange questões como gestão de pessoas, orçamento, contratos. 
– Ambiente Atividades que dão suporte à equipe de desenvolvimento, como os itens de IT, servidores, 
ferramentas. 
Essas disciplinas têm suas responsabilidades e funções variadas, dependendo da fase que se encontra o projeto. 
No processo RUP, o tempo está dividido em 4 fases. 
– Concepção Estabelecer o escopo e viabilidade econômica do projeto. 
– Construção Desenvolver o produtor até que ele esteja pronto para beta testes. 
– Transição Entrar no ambiente do usuário. Desenvolver o produtor até que ele esteja pronto para beta testes. 
– Elaboração Eliminar principais riscos e definir arquitetura estável. 
 
CONTEXTO:ESTADO DA ARTE 
 Engenharias Tradicionais valorizam o Projetar ANTES de Construir. 
 Engenharias Tradicionais não exergam o processo de desenvolvimento de SW como ele é: Com mudanças 
sempre. 
 Necessidade: Metodologia que permita alteração frequente do SW sem afetar sua qualidade. 
 Um grupo de desenvolvedores QUER processo menos burocrático e + prático. 
ENGENHARIA DE SOFTWARE DESEJO DAS METOD. ÁGEIS 
 
 
 
PROCESSO DE DESENV. ÁGIL 
 Baseado em um MANIFESTO, criado por desenvolvedores experientes 
• Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando 
outros a fazerem o mesmo. 
• Foco em pessoas e não em ferramentas 
• Mudanças nos valores; 
MANIFESTO ÁGIL 
Valoriza-se: 
 Indivíduos e interações mais que processos e ferramentas 
 Software em funcionamento mais que documentação abrangente 
 Colaboração com o cliente mais que negociação de contratos 
 Responder a mudanças mais que seguir um plano 
PROCESSO DE DESENV. ÁGIL 
 Nossa maior prioridade é satisfazer o cliente 
 Mudanças nos requisitos são bem-vindas, mesmo 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. 
 Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário 
 O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é 
através de conversa 
 Software funcionando é a medida primária de progresso 
 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu 
comportamento 
MÉTODO XP 
• XP= eXtreme Programming. 
• Baseado em 5 valores 
– Comunicação, 
– Coragem (para lidar c/ mudança requisito) 
– Feedback, 
– Respeito (entre membros da equipe) 
– Simplicidade (fazer o necessário). 
 Práticas do método xp 
 Reuniões em pé 
 Programação em par 
 Teste de aceitação 
 Posse coletiva 
 Pequenas versões 
 Ritmo sustentável 
 Padrão de codificação 
MÉTODO SCRUM 
 O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e 
desenvolvimento ágil de software. Uso: trabalhos complexos, onde não há previsão exata do que se pretende 
desenvolver. O projeto é dividido em ciclos (sprints).O sprint é a iteração, no caso do SCRUM. 
MODELO SCRUM 
• Product Backlog : Lista com Funcionalidades a serem implementadas. 
• Sprint Backlog: Análise dos requisitos para informar equipe como será implementado. 
• Sprint: Período para finalização de cada requisito 
• Scrum: Reunião diária para análise de andamento 
• Scrum Master: Coordenador (não estourar o sprint) 
RUP - Rational Unified Process 
– Processo proprietário de desenvolvimento de software, criado pela Rational, que foi adquirida pela IBM. 
– Baseado em OO. 
– Processo pesado 
– Uso em grandes projetos 
– Desenvolver iterativamente 
– Gerenciar requerimentos  uso de casos de uso 
– Foca arquitetura baseada em componentes 
– Utiliza UML  modelagem visual 
– Qualidade durante todo o processo 
– Gestão e controle de mudanças 
– Disciplinas + fases + iterações. 
– Disciplinas 
 Modelagem de negócios 
 Requisitos 
 Análise e design 
 Implementação 
 Teste 
 Implantação 
 Configuração e mudanças 
 Projeto (gestão de pessoas, orçamento e contratos) 
 Ambiente (servidores, ferramentas, Bds..) 
As FASES do RUP 
 
RUP 
2 dimensões 
 Eixo horizontal 
o Representa o TEMPO 
o Mostra os aspectos do ciclo de vida a medida que se desenvolve: FASES E ITERAÇÕES 
 Eixo vertical 
o Representa as DISCIPLINAS, que agrupam as atividades