Rio de Janeiro 22 de Outubro de 2010
Aula 1: Processo de desenvolvimento de software Objetivo: 1. Definir o que é Software. 2. Identificar as aplicações do Software. 3. Compreender os fluxos de dados em um sistema de informação.
Introdução. Olá! Seja bem vindo à nossa primeira aula! Nesta aula, iremos definir o conceito de software, quais as suas características e aplicações. Veremos, ainda, o fluxo de informação para a geração de conhecimento.
O software.
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.
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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
4
Existem basicamente duas classificações para a linguagem de programação.
Estruturada: Elementos de código em formato de blocos que se interligam através de três métodos básicos: • Sequência: Onde os passos são seguidos de forma sequencial (tarefa 1 finaliza, entra tarefa 2). • Seleção: Onde os passos podem ser executados baseados em um tratamento lógico (IF, THEM, ELSE). • Interação: Onde os passos podem ser repetitivos até uma condição ser atingida.
Orientada a Objeto (OO): Elementos de código em formato de objetos que se interligam. • Classe: Tipo de Objeto. • Atributos: Variáveis que estão dentro de cada objeto da classe. • Método: Ação que a classe pode realizar.
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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
5
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:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
6
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
7
Nesta aula, você:
• • • •
O que é um software. Quais os tipos de software que existem e suas classificações. Quais os tipos de licença de uso de software existentes. O Fluxo de processamento de dados para gerar informação e conhecimento.
Algumas definições de software:
http://pt.wikipedia.org/wiki/Software
Na próxima aula, veremos quais os requisitos que devem ser levantados para viabilizar o desenvolvimento de um software.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
8
Aula Tele transmitida: SISTEMA DE INFORMAÇÃO Sistema = Conjunto de partes, independentes, cada qual com seu objetivo, mas 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 é
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.
5.000,00
SISTEMA DE INFORMAÇÃO Manual e baseado em computador
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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
9
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 comandam a operação do computador. Tipos de Software, quanto a natureza Software de Sistema: controlam as operações do computador: software da BIOS, SO Software aplicativo 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: 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?
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
10
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 REALIDADE. CRISE DO SOFTWARE
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
11
CICLO DE VIDA DO SOFTWARE 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 SISTEMAS? Passado Necessidades Programação (CAOS) Hoje Projeto para desenvolver um SW Processo de desenvolvimento Qual a finalidade do SW? Quais as funções o SW terá? Como essas funções se integrarão? Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
12
Como o SW se integrará ao contexto da empresa? Quanto tempo terei para construí-lo? 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:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
13
Compreende o que será considerado para o desenvolvimento. Quanto maior o escopo, maior a complexidade e dificuldade de gerenciar o desenvolvimento.
Requisito – Necessidades do usuário: Compreende as funcionalidades que o sistema deve possuir. Fundamental – Definir os requisitos que farão parte do escopo. 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 – boas chances 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, Retrabalho, perda de trabalho feito O mesmo que alterar a planta estrutural de uma casa, após iniciada a construção.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
14
A boa engenharia de requisitos tende a reduzir a instabilidade, obtendo os requisitos no momento oportuno.
Anotações da Aula:
Sistemas de Informação utiliza-se da Tecnologia da Informação que, por sua vez, são recursos computacionais que provém as informações desejadas. Algoritmo é a lógica que está por trás do Software. Os recursos Humanos são de extrema importância, pois além de criarem os algoritmos, são quem manuseiam os softwares. O software não acompanhou, na mesma proporção, o Hardware, o Banco de Dados e a parte de Rede, ou seja, não evoluiu de forma exponencial quanto as partes citadas evoluíram. A reutilização de códigos é importante para agilidade do processo de desenvolvimento. Antigamente
aferia-se as necessidades e partia-se diretamente para fase de programação, o que gerava o caos. Hoje, existe o projeto para desenvolver o Software e o processo de desenvolvimento previamente definido, afim de evitar custos e insatisfações.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
15
Rio de Janeiro 29 de Outubro de 2010
Aula 2: Processo de desenvolvimento de software Objetivo: 1. Descrever as atividades para análise dos requisitos no processo de desenvolvimento de software. 2. Desenvolver técnicas para elicitar e analisar requisitos. 3. Entender o gerenciamento de requisitos.
Introdução. Olá! Seja bem vindo à nossa aula! Nesta aula, iremos definir o conceito de requisito para o processo de desenvolvimento de software. 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?
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
16
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. 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. 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. 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.
REQUISITOS NÃO FUNCIONAIS
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
17
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
18
Técnicas de elicitação
Nesta aula, você: • • •
A importância de fazer uma análise inicial de requisitos para reduzir os risco de erros no decorrer do processo. Quais tipos de requisitos existem e suas classificações. Algumas técnicas de elicitação para identificar falhas e propor soluções.
Algumas técnicas e definições sobre o levantamento de requisitos: http://pt.wikipedia.org/wiki/Analise_de_requerimento_de_software
Na próxima aula, veremos a etapa de análise onde se trabalha e modela os requisitos para se obter uma estrutura para auxiliar no desenho da solução.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
19
Aula Tele transmitida BEM-VINDO À DISCIPLINA PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MARCELO VASQUES – AULA 2 OBJETIVOS DA AULA Apresentar Estudo de Viabilidade
Definir conceito e tipos de Requisitos
Descrever atividades para análise de requisitos
Apresentar técnicas para elicitar e analisar Requisitos
ANÁLISE DE VIABILIDADE Concepção Semente Necessidade, ideia 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 apoia a área de negócios
Saída: 1. Viável? (técnica, operacional e financeiramente) 2. O SW contribui para os objetivos da organização? Beneficia os interessados? 1. Viabilidade Operacional Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
20
3. O SW pode ser implementado com TI atual? 1. Viabilidade Técnica 4. Restrições de custo serão atendidas? 1. Viabilidade econômica 5. Restrições de prazo serão atendidas? 1. 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 a taxa, 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 períodos.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
21
ENGENHARIA DE REQUISITOS Elicitação Elicitar = descobrir, tornar explícito. Explicar 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 DOS 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 REQUISITOS FUNCIONAIS 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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
22
LEVANTAMENTO DE DADOS – TÉCNICAS Entrevista: Quando usar: Primeiras técnicas a serem usadas com alto escalão: entendimento da organização (organograma). Fechadas (questionário) ou abertas (roteiro) Individual ou pequeno grupo V - Eficiente D - Cara (falta de tempo das pessoas). V- Permite observar postura corporal. “Olhar nos olhos”. D - Cuidado: não se perder (roteiro) Questionário Quando usar: Muitos usuários e há necessidade de uma análise estatística. Quando usar: Falta de tempo dos envolvidos para entrevistas. Quando usar: 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 Considera o procedimento atual ( ) Ruim ( ) Satisfatório Brainstorm (Tempestade de ideias) Reuniões onde participam todos os envolvidos: usuários finais, analistas e clientes. Objetivo: permitir que todos expressem suas ideias de forma a obter o consenso. Todos expressão de forma desorganizada mesmo Organizam-se as ideias Identifica-se conflitos entre áreas Visões diferentes do requisito nas empresas.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
23
Casos 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 requisi tos 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. GESTÃO DOS REQUISITOS Problema: Instabilidade nos Requisitos: Novos requisitos e Alterações de requisitos com o desenvolvimento já adiantado. Alto custo, Retrabalho, perda de trabalho feito O mesmo que alterar a planta estrutural de uma casa, após iniciada a construção. Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
24
A boa engenharia de requisitos tende a reduzir a instabilidade, obtendo os requisitos no momento oportuno. GESTÃO DOS REQUISITOS Levantamento dos requisitos Validação dos requisitos Gerenciamento dos requisitos (mudanças e novos)
Anotações da Aula Técnica de levantamento de requisitos não é uma fase. • • o o o
Análise básica de viabilidade: Aferir os inputs; Concluir o output Técnica Se a TI disponível irá suportar; Operacional Se a organização irá absorver sem maiores contratempos; Financeiro Qual o retorno irá trazer. Custo-benefício.
Quando o software lançado, já é lançado obsoleto, pode não ter sido calculado ou respeitado o prazo de forma correta. A parte técnica pode mudar durante um projeto, mas tem sempre que ser para melhor, pois partimos do princípio de que a tecnologia sempre evolui e, não regride.
Elicitar descobrir. Tornar explícito; obter o máximo de informações para o conhecimento do objeto em questão. Requisitos de usuário saber das necessidades do usuário/cliente; Abstrato – alto nível. Requisitos de sistema mediante as necessidades do usuário, aferir as necessidades do sistema e ver se a TIC suporta ou não; detalhado. Ou seja, de um modo geral isso significa: o que é? E, como é? Requisitos funcionais Estabelece o que o sistema deve, ou não, fazer. Requisitos não-funcionais Restrições sobre serviços ou funções do sistema; não são inerentes ao negócio. Importante validar o levantamento dos requisitos, usando, por exemplo, o caso de uso.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
25
Rio de Janeiro 05 de Novembro de 2010
Aula 3: Atividade de análise no processo de desenvolvimento de softwares Objetivo: 1. Conhecer as atividades de análise de desenvolvimento de software. 2. Entender os relacionamentos dos objetos. 3. Modelar os relacionamentos dos objetos.
Introdução Olá! Seja bem vindo à nossa aula! Nesta aula, iremos definir o conceito de análise para o processo de desenvolvimento de software. 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
26
Objeto e classe
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 identificar soluções para os requisitos apresentados.
de requisitos para visualizar e fornecer base para
Atividades dentro da análise estruturada Identificação de Classes: 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. Organização das Classes: 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: ajuda a filtrar e refinar as classes.
Identificação dos Atributos: A cada classe é atribuída uma característica responsável por tomar alguma ação. Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
27
Análise 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:
Receptor
Operação
Parâmetro
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. Identificação das Operações: Todas as mensagem devem se mapeadas para executarem alguma operação. Podem ser: Incluir, Alterar, Excluir, dentre outras.
Nesta aula, você aprendeu: • • •
A importância de fazer uma modelagem para identificar se há uma falha no levantamento de requisitos. Quais os tipos de análise existem e suas classificações. A criar relacionamentos entre classes.
Na próxima aula, veremos a etapa de desenho onde se trabalha e modela os requisitos para se obter uma estrutura para auxiliar no desenho da solução.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
28
Aula Tele transmitida PROCESSOS DE DESENVOLVIMENTO DE SW - PROF. MARCELO VASQUES – AULA 3 MATERIAL IMPRESSO Aula 1: Capitulo 1 (Engenharia de Aula 4: Capitulo 10 (Engenharia de Software): Padua Software): Sommerville Aula 2: Capitulo Software): Gustavson
8
(Engenharia
de
Aula 5: Capítulo 10 (Engenharia de Software): Gustavson
Aula 3: Capitulo Software): Gustavson
8
(Engenharia
de
Aula Tele 4 – gravada em 08/11 Aula Tele 5 – ao vivo, amanha, sábado, as 8:55h
OBJETIVOS DA AULA Conhecer as atividades de análise do processo de desenvolvimento
Entender as técnicas de modelagem, especialmente orientada a objeto
Conhecer os fundamentos essenciais da UML
FASE: ANÁLISE Estudar, entender e modelar o problema Modelar = criar modelos 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
29
A 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. MUDANÇA DE ENFOQUE
ENCAPSULAR = ESCONDER
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
30
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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
31
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CLASSES
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
32
DIAGRAMA DE SEQUENCIA
: TelaSaque
C1: ContaCorrente
L1: Lancamento
Correntista senha validarSenha(senha)
saque verificarSaldo()
bloquearValor(saque) efetuarLancamento(C1)
debitarValor(saque) efetuarLancamento(C1)
aviso de liberação
TRIPÉ DA ANÁLISE
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
33
Rio de Janeiro 06 de Novembro de 2010
Aula 4: O desenho no processo de desenvolvimento de software Objetivo: 1. Conhecer as atividades de desenho ou arquitetura no processo de desenvolvimento de software. 2. Diferenciar os modelos de desenhos para as suas atividades. 3. Entender as necessidades de desenhar a solução analisando os requisitos. Nesta aula, iremos definir o conceito de desenho para o 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
Modelos de desenho
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
34
Reutilização Nesta fase, é comum se fazer uso de processos que já foram definidos e utilizados em outras fases do produto ou sistema. 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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
35
Nesta aula, você aprendeu: • • •
A importância de se fazer uma desenho bem feito de uma solução ou serviço. Identificar os atores aos quais serão apresentados os desenhos. A importância da reutilização para redução de desperdício aumentando a eficiência.
Na próxima aula, veremos a etapa de codificação onde será apresentada a parte de desenvolvimento do código baseado nos modelos e desenhos apresentados.
Aula Tele transmitida PROF. MARCELO VASQUES MATERIAL IMPRESSO CAPÍTULO 10 – LIVRO ENGENHARIA DE SOFTWARE – IAN SOMMERVILLE – 6ª EDIÇÃO. OBJETIVOS DA AULA Conhecer as atividades de desenho ou arquitetura do software dentro do processo de desenvolvimento
Entender a necessidade de desenhar a solução analisando os requisitos e soluções da fase de Análise
Apresentar as diferentes visões a serem consideradas na fase de desenho ou projeto do software
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 Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
36
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 subsistemas. 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 SOFTWARE 1. Estruturação do sistema
Sistema é estruturado em subsistemas
Subsistema=unidade SW independente
Comunicação entre subsistemas
2. Modelagem de controle
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
37
Modelo de relacionamento entre as partes de um sistema
3. Decomposição modular
Cada subsistema é divido em módulos
ESTRUTURAÇÃO DO SISTEMA
MODELOS DE CONTROLE 1. CENTRALIZADO
1 Subsistema tem controle geral
Inicia e interrompe os subsistemas
Aguarda que o controle retorne
RETORNO DE CHAMADAS
CENTRALIZADO – TEMPO REAL
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
38
MODELOS DE CONTROLE 1. Orientado a eventos
EVENTOS gerados externamente
Subsistema não controla eventos.
Modelos de:
Transmissão
Orientado a interrupções
CONTROLE P/TRANSMISSÃO
CONTROLE P/INTERRUPÇÕES
DECOMPOSIÇÃO EM MÓDULOS Modelo orientado a objetos
Diagrama de classes
Diagrama de componente
Interação
Diagrama de sequencia.
Diagrama de Atividade
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
39
DIAGRAMA DE CLASSE
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.
DIAGRAMA DE COMPONENTES
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
40
DIAGRAMA DE COMPONENTES
META: REUTILIZAÇÃO Ideia: 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
DEMAIS ATIVIDADES Definições
Interface com usuário
Arquitetura de hardware e SO.
Linguagem de programação
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
41
Estrutura de rede e comunicações
SGBD – banco de dados
Anotações da Aula Começar pelo diagrama de casos de uso, depois o diagrama de classes, que irá especificar as classes do sistema e, por último, o diagrama de sequência, que irá mostrar como as classes se relacionam para atender o sistema. As interfaces têm que ter um bom modelo de interação com o usuário para que isto seja um diferencial com os modelos concorrentes. Pesquisar símbolos de diagramas de classes e/ou fluxograma. A tecnologia entra na fase de arquitetura na parte de decomposição modular.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
42
Rio de Janeiro 06 de Novembro de 2010
Aula 5: As atividades de teste no processo de desenvolvimento de software Objetivo: 1. Conhecer as atividades de teste no processo de desenvolvimento de software. 2. Entender as necessidades da etapa de teste na melhora da qualidade do sistema. 3. Analisar os diversos tipos de teste para sistema ou produto. Nesta aula, iremos definir o conceito de teste para o 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
43
Modalidade dos testes
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
44
Nesta aula, você:
• • • •
A A A A
importância de se fazer testes durante o processo de desenvolvimento de software. identificar quais tipos de testes existem e devem ser utilizados. levantar as necessidade e separar os testes por grupos de análise. importância de se ter uma equipe de teste diferente da equipe de desenvolvimento.
Na próxima aula, veremos a etapa de codificação onde será apresentada a parte de desenvolvimento do código, baseada nos modelos e desenhos apresentados anteriormente.
Aula Tele transmitida PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MARCELO VASQUES – AULA 5 1ª. DEFINIÇÃO • 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 rel2gada a segundo plano ou mesmo esquecida.
FASE: TESTES 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 ou Testes DURANTE OU APÓS a implementação Precisa de parte ou todo sistema encarnado Qualidade no produto
Objetivo: encontrar erros não descobertos
Bem sucedido: Acha erro não previsto
É preciso usar o produto
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
45
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.
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? Objetivo: 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. 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 e erros. TESTE DE UNIDADE 1ª. Etapa do processo de validação.
Testa 1 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.
Juntas e integradas, as unidades funcionam
Cuidado: alteração de componentes.
Aplicar testes de caixas branca e preta
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
46
TESTES DE SISTEMAS (VALIDAÇÃO) Estágio mais complexo da validação
Validam a solução como um todo.
Aqui: as falhas individuais já estão sanadas (espera-se).
Ambiente (Hw, SO, rede e etc) bem próximo da realidade da operação).
Testar: integração com sistemas externos, dispositivos físicos (hw)
Dificuldade: vislumbrar os vários cenários de uso.
TESTES DE ACEITE Ú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
Planejar os testes
Documentar os testes
Validar ao longo do processo.
Não “queimar” etapas de testes
Equipe especializada - <> da equipe de desenvolvimento
IMPORTANTE
Anotações da Aula O usuário não deve testar o produto, mas sim validá-lo, ou seja, nunca devemos pular a fase de testes. Testes estáticos têm o foco no processo, enquanto testes dinâmicos no produto.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
47
Rio de Janeiro 23 de Novembro de 2010
Aula 6: A implementação do sistema de software Objetivo: 1. Conhecer as atividades de implementação no processo de desenvolvimento de software. 2. Entender as necessidades de definir uma tecnologia para a transformação do desenho para o projeto em um sistema binário. 3. Analisar os diversos tipos de produto e utilizar a linguagem que atenda às necessidades. 4. Analisar a possibilidade de automatizar o processo de construção do código fonte. Nesta aula, iremos definir o conceito de implementação para o 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 Etapa do processo de desenvolvimento de desenho em diversos tipos de componentes software já estudada anteriormente. de código de programação.
O código de programação pode ser dividido em 3 tipos:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
48
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 de terceira geração
Surgida em meados dos anos 50, foi considerada a Em meados dos anos 80, surgiram o conceito de primeira linguagem de alto nível, visto que era de programação estruturada e a programação orientada fácil entendimento e, portanto, considerada mais a objeto. humana. Ex: COBOL, Pascal, FROTRAN.
Linguagem de quarta geração É característica dessa linguagem 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
49
Nesta aula, você:
• • •
A importância de conhecer as linguagens de programação para o sucesso da implementação no processo de desenvolvimento de software. Identificar as linguagens de programação mais comuns. A importância de documentar os passos de implementação.
Na próxima aula, veremos a etapa de documentação e manutenção do produto no processo de desenvolvimento de software.
Aula Tele transmitida PROF. MARCELO VASQUES – AULA 6 1ª. DEFINIÇÃ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. •
As empresas costumam definir padrões para o desenvolvimento.
FASE IMPLEMENTAÇÃO 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. 1. 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. Nos primórdios a linguagem era essa. Difícil !!!!
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
50
2. LINGUAGEM ASSEMBLY
3. LINGUAGEM DE ALTO NÍVEL
COMPARAÇÃO LINGUAGENS
COMO CONVERTER ? Homem (alto nível) Máquina (baixo nível) 2 processos fazem esse papel Interpretação (Interpretador) TRADUZ O CÓDIGO A MEDIDA QUE EXECUTA Pilhona, Pearl, PHP, Javascript, ASP Compilação
(Compilador)
TRADUZ E DEPOIS EXECUTA C++, Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
51
INTERPRETAÇÃO Interpretação é a "tradução" do código em linguagem de máquina em tempo de execução. É utilizada: PHP, ASP, Javascript. Uma característica marcante das linguagens interpretadas são que elas executam o código até o ponto em que há um erro. Por acontecer em tempo de execução,tipicamente tem um desempenho um pouco menor.
COMPILAÇÃO Primeiro, faz uma leitura completa do código, identificando variáveis e outros elementos e montando uma tabela com estas informações. 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. 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. Compiladores modernos conseguem enormes otimizações em certos códigos. COMPILADOR / HÍBRIDO
AMBIENTES DESENVOLVIMENTO Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
52
AMBIENTES DESENVOLVIMENTO
JAVA
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
53
BOA PRÁTICA- PROGRAMAÇÃO Documentar com comentários o código fonte // este procedimento visa calcular o digito verificar com base no modulo 11 // Data:
Autor:
Data alteração:
Bons nomes – autoexplicativos e padronizados variável: NA ?? Variável: nome_aluno
Anotações da Aula Fase de implementação é a fase do programador, onde ele implementa o que foi definido na etapa de desenho PHP, ASP, JAVASCRIPT são linguagens interpretadas. Código objeto são códigos intermediários em linguagem de montagem que se juntam a outros objetos para gerarem o código de máquina; não é um executável. Compilador traduz a linguagem de alto nível para assembly (linguagem de montagem) e; Montador traduz de linguagem de montagem (assembly) para linguagem de máquina(código de máquina).
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
54
Rio de Janeiro 24 de Novembro de 2010
Aula 7: A documentação do sistema de software Objetivo: 1. Conhecer as atividades de documentação, suporte e melhoria no processo de desenvolvimento de software. 2. Entender as necessidades de documentar as atividades, os processos e procedimentos durante o desenvolvimento de um sistema. 3. Analisar as diversas formas de documentação e sugestões de melhoria. 4. Entender a necessidade de suporte para correção de erros que possam aparecer depois da concepção do sistema. 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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
55
Documentação do processo
Nesta aula, você aprendeu:
• •
•
A importância de utilizar uma padronização da documentação no processo de desenvolvimento de software. A diferença dos tipos de documentação e para quem se destinam. A importância de documentar todos os passos do processo de desenvolvimento de software.
Na próxima aula veremos o processo cascata, modelo de desenvolvimento de software sequencial que esta dentro do processo de desenvolvimento de software.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
56
Aula Tele transmitida PROF. MARCELO VASQUES – AULA 7
ATIVIDADES DA MANUTENÇÃO
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
57
AFETAM O CUSTO DA MANUTENÇÃO
MANUTENÇÃO COMO PROJETO
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
58
COMO ACUMULAR DEMANDAS
DOCUMENTAÇÃO PARA SUPORTE
DOCUMENTAÇÃO PARA MANUTENÇÃO
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
59
DOCUMENTAÇÃO DO PROCESSO
Anotações da Aula A fase de requisitos é a mola propulsora de todo sistema, ou seja, são os insumos que os usuários nos dão. A fase de análise estuda os requisitos e define o que o sistema vai fazer. A fase de desenho ou projeto é a fase mais física e de arquitetura, onde se pensa quais vão ser os componentes, como vão se encaixar e que funções terão. A implementação é onde se escolhe a linguagem, o ambiente, o banco de dados e escrever o programa. A fase de teste tem como objetivo aferir se tudo que foi desenvolvido está em conformidade com os requisitos e com os padrões de qualidade que a empresa estabeleceu. A fase de manutenção não é uma fase só de correção de erros. A manutenção tem que atender a correção de erros, melhorias nas funções existentes e implementar novas funções. Temos que separar o que é correção, melhoria e novas funções.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
60
Rio de Janeiro 27 de Novembro de 2010
Aula 8: O desenvolvimento do software em cascata Objetivo: 1. Conhecer o processo em cascata, modelo de desenvolvimento de software sequencial, dentro do modelo de desenvolvimento de software. 2. Entender as vantagens do modelo e suas limitações. 3. Analisar as etapas iniciais do processo de desenvolvimento de software e aplicá-las no modelo em cascata.
Nesta aula iremos demonstrar o modelo de desenvolvimento de software em cascata. Inicialmente, não se seguia um modelo de desenvolvimento de software. Os desenvolvedores baseavam-se em suas próprias experiencias 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
61
Modelo cascata
Vantagens 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 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. Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
62
Modelo cascata com realimentação
Vantagens Possibilidade de correção de erros durante o processo de desenvolvimento de software. Desvantagens Dependendo da quantidade de revisões e realimentações, o processo pode se tornar difícil de gerenciar.
Nesta aula, você:
• •
•
A importância de utilizar processo definido de desenvolvimento de software. Utilizar as etapas estudadas anteriormente no processo em cascata. A importância de documentar todos os passos do processo de desenvolvimento de software.
Na próxima aula, veremos o processo iterativo, modelo de desenvolvimento de software que está dentro do processo de desenvolvimento de software.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
63
Aula Tele transmitida PROF. MARCELO VASQUES – AULA 8 MATERIAL IMPRESSO Aula 8: Capítulo 5 (Processos de Software): do Livro Engenharia de Software – Fundamentos, Métodos e Padrões do Wilson de Paula Filho OBJETIVOS DA AULA Conhecer os processos em Cascata - tradicional e com retroalimentação
Entender as vantagens e limitações dos modelos
Aplicar as fases do processo ao modelo.
CONTEXTO Anos: 70/80 Antes: Não era usado nenhum 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 sistema implantado. MODELOS INICIAIS Modelo Balburdia 2 fases: Implementação & Correção Modelo Codifica-remenda Similar ao balburdia Surge a ideia de necessidades após implantação, pois os sistemas tornavamse maiores. CICLO DE VIDA DO PROJETO Atividades ordenadas, com fluxo contínuo para auxiliar o acompanhamento do projeto. Atividades Fluxo de informações Relacionamento entre atividades MODELO CASCATA 1º. Modelo em Engenharia de Software Linear cada atividade tem que ser concluída antes de iniciar a próxima.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
64
Útil: pequenos projetos Importância: base para outros modelos. Característica: usada até hoje.
Vantagem
Permite pontos de controle bem definidos facilita gestão do projeto
Requer documentação todas as fases.
Em tese só avança se cliente Valida fase atual Participação do usuário
Simples de implementar e gerir.
MODELO CASCATA – DESVANTAGENS Todos os requisitos devem ser descobertos no início -- > não prevê alteração nos requisitos Projeto raramente seguem fluxo sequencial iterações (vários ciclos) são necessárias. Não prevê manutenção. Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
65
Baixa visibilidade ao usuário só vê os resultados ao final Dificulta visão de reutilização. Se ocorrer atraso , todo o processo é afetado; Só gestor tem visão do todo. CASCADA C/RETROALIMENTAÇÃO Variante “cascata tradicional” que permite a realimentação, ou seja, correções que surgirem durante outras fases do processo. Modelo que permite a revisão de fases anteriores e a superposição entre as fases. Porem o custo dessa revisão pode ser alto, dependendo da fase atual e do quanto se precisa retroceder CASCADA C/RETROALIMENTAÇÃO
CASCADA C/RETROALIMENTAÇÃO Vantagem Possibilita a correção de erros nas fase(s) anterior(es), durante o processo de desenvolvimento. Prevê manutenção Desvantagem Dependendo da quantidade de revisões e realimentações, o processo pode se tornar difícil de gerenciar.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
66
Rio de Janeiro 02 de Dezembro de 2010
Aula 9: O processo iterativo e incremental Objetivo: 1. Conhecer o processo iterativo e incremental, modelo de desenvolvimento de software variante do processo em cascata. 2. Entender as vantagens do modelo e suas limitações. 3. Analisar as etapas iniciais do processo de desenvolvimento de software e aplicá-las no modelo iterativo.
Olá! Seja bem vindo à nossa aula! Nesta aula, iremos demonstrar o modelo de desenvolvimento de software iterativo. Como vimos anteriormente, o modelo em cascata, também conhecido como “water fall” ou “TopDown”, 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
67
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:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
68
Modelo espiral
Exemplo:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
69
Nesta aula, você: • • •
A importância de se utilizar um processo definido de desenvolvimento de software. Utilizar as etapas estudadas anteriormente no processo em cascata e aplicá-las no iterativo e incremental. A importância de documentar todos os passos do processo de desenvolvimento de software.
Na próxima aula, veremos o processo unificado, modelo de desenvolvimento de software que está dentro do processo de desenvolvimento de software.
Aula Tele Transmitida PROF. MARCELO VASQUES AULA 9 CONTEXTO PROCESSO ITERATIVO Seleção de uma parte do projeto Identifica, especifica, implementa, testa e implanta a iteração Se atender as especificações, passa-se a próxima iteração. PROCESSO 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. PROCESSO INCREMENTAL MODELO ITERATIVO E INCREMENTAL Processo 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. MODELO ITERATIVO E INCREMENTAL 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
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
70
MODELO: PROTOTIPAÇÃO Tipos de protótipo: em papel ou sistema: retratam a interface e interação em sistema, implementando algumas funções Quando usar? 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 desenvolvedor não tem certeza da eficiência de um algoritmo ou forma da interação. MODELO: PROTOTIPAÇÃO 1- OBTENÇÃO DOS REQUISITOS O desenvolvedor e o cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais. 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 PROTÓTIPO É 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 Cliente e desenvolvedor avaliam o protótipo. 5- REFINAMENTO DOS REQUISITOS: Com base na avaliação, refinam o produto 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: A versão de produção deve ser construída considerando os critérios de qualidade. 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. MODELO: ESPIRAL Cada volta da espiral representa uma fase do processo: Definição dos objetivos - Especificação dos objetivos específicos da fase; Análise dos riscos - Identificação e solução dos principais riscos
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
71
Desenvolvimento e validação; Planejamento - O projeto é revisto e são definidos os planos para a próxima “volta da espiral”. MODELO: ESPIRAL 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.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
72
Rio de Janeiro 02 de Dezembro de 2010
Aula 10: Outros processos do desenvolvimento de software Objetivo: 1. Conhecer outros processos utilizados no processo de desenvolvimentos de software. 2. Entender as vantagens dos modelos e suas limitações. 3. Analisar as etapas iniciais do processo de desenvolvimento de software e compará-los. Nesta aula, iremos demonstrar outros modelos 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 Método Á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.
Método XP Também conhecido como eXtreme Programming, é um método1 que pertence à metodologia ágil de desenvolvimento de software. É baseado em 5 valores:
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.
1
O modelo propõem uma série de práticas focados em pessoas, ou seja, na equipe de desenvolvimento.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
73
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. Método 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:
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
74
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 ou Iniciação Tem como objetivo dar ênfase ao escopo do sistema como um todo. Construção Tem como objetivo verificar o andamento do projeto e suas atividades. Transição Tem como função dar ênfase à implementação do sistema. Elaboração Tem como função dar ênfase ao design ou arquitetura do produto.
Nesta aula, você: • • •
A importância de utilizar processos definidos de desenvolvimento de software. Utilizar a Metodologia Ágil no processo de desenvolvimento de software. A comparar os métodos existentes de desenvolvimento de software.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
75
Aula Tele Transmitida PROF. MARCELO VASQUES – AULA 10
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
76
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
77
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
78
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
79
Anotações da Aula Processos ágeis são menos burocráticos, valorizando mais a parte prática. Processos ágeis é o equilíbrio entre documentação e implementação. É mais informal.
Raphael da Silva Roma Matrícula: 2010.01.50934-1
2º Período – 2º Módulo 2010.4
Sistemas de Informação
80