RETA FINAL: Tecnologia da Informação

Transcrição

1 RETA FINAL: Tecnologia da Informação MODELOS ORGANIZACIONAIS Modelos sequenciais: Os modelos sequenciais são aqueles em que o trabalho flui de forma relativamente linear. O principal modelo sequencial conhecido é o modelo em cascata, também chamado de ciclo de vida clássico. Modelo em Cascata: Pressman 1 de 18

2 Modelo em cascata: Royce Uma variação do modelo cascata é o modelo V. O modelo V procura relacionar as ações de garantia da qualidade com as ações iniciais relacionadas à comunicação, modelagem e atividades de construção iniciais. Modelo em V 2 de 18

3 Modelos incrementais Os modelos incrementais surgiram como uma alternativa aos modelos sequenciais. Tais modelos combinam elementos dos fluxos de processos lineares e paralelos. Modelo Incremental Ciclo RAD 3 de 18

4 Modelos evolutivos Prototipação O modelo espiral é um modelo de processo de software que acopla a natureza iterativa da prototipação com aspectos sistemáticos do modelo cascata. Nele, cada volta na espiral conduz a versões cada vez mais sofisticadas do software. Ainda, cabe destacar duas características do modelo em espiral que o diferem dos demais. Primeiro, o modelo em espiral não precisa se encerrar na entrega da versão final ao cliente, pois ele pode englobar também as fases de manutenção e evolução do software; e, por fim, este modelo reconhece explicitamente os riscos do processo de desenvolvimento, uma vez que desenvolvedor e cliente podem utilizar a prototipação como mecanismo de redução dos riscos. Modelo em espiral de Boehm 4 de 18

5 RESUMO COMPARATIVO ENTRE OS TRÊS PRINCIPAIS MODELOS SEQUENCIAL INCREMENTAL EVOLUCIONÁRIO Como funciona Atividades em sequência Misto de atividades sequenciais e em paralelo Desenvolvimento em ciclos Vantagem Útil apenas quando a atividade é muito bem limitada e definida Útil quando o produto permite entregas seccionadas Reconhece os riscos explicitamente; reconhece o dinamismo do software Desvantagem Dificilmente um projeto real segue essa abordagem Nem todo software acomoda esse tipo de entrega Pode ser difícil convencer o cliente aceitar esse tipo de entrega ENGENHARIA DE REQUISITOS REQUISITOS Requisitos são uma especificação do que deve ser implementado. Eles constituem descrições de como o sistema deve ser comportar, ou uma propriedade ou atributo do sistema. Podem caracterizar uma restrição no processo de desenvolvimento do sistema. Sommerville Classificação dos requisitos quanto à natureza: Requisitos funcionais: São as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais também podem estabelecer explicitamente o que o sistema não deve fazer. Requisitos não-funcionais: São restrições sobre os serviços ou as funções oferecidos pelo sistema. Eles incluem restrições de timing, restrições sobre o processo de desenvolvimento e padrões. Os requisitos não funcionais aplicam-se, frequentemente, ao sistema como um todo. 5 de 18

6 Requisitos de domínio: São requisitos provenientes do domínio da aplicação do sistema e que refletem as características e restrições desse domínio. Podem ser requisitos funcionais ou não funcionais. Classificação dos requisitos quanto à visibilidade: Requisitos de usuário: São declarações, em linguagem natural e diagramas, de modo que eles sejam compreensíveis pelos usuários do sistema que não possuam conhecimento técnico detalhado. Requisitos de sistema: Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos do sistema, também chamado de especificação funcional, pode ser parte do contrato entre o comprador do sistema e o desenvolvedor do software. Requisitos de desenho (ou especificação de projetos de software): Especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento. Classificação dos requisitos quanto à qualidade: Requisitos normais: Refletem os objetivos e metas estabelecidos para um produto ou sistema durante reuniões com o cliente. Se esses requisitos estiverem presentes, o cliente fica satisfeito. Relaciona-se, principalmente, com os requisitos funcionais. Requisitos esperados: São requisitos implícitos no produto ou sistema e podem ser tão fundamentais que o cliente não os declara explicitamente. Sua ausência gera grande insatisfação. Via de regra, são requisitos não-funcionais. Requisitos fascinantes: São recursos que vão além das expectativas dos clientes e demonstram ser muito satisfatórios quando presentes. Por exemplo, seria uma aplicação para celular que, inesperadamente, oferecesse suporte multitouch. 6 de 18

7 STAKEHOLDERS Stakeholders (ou interessados, ou partes interessadas) são aqueles que se beneficiarão de forma direta ou indireta do sistema que está sendo desenvolvido. É importante mapear todos stakeholders de um software a ser desenvolvido. Cada interessado tem uma visão diferente do sistema, obtém diferentes benefícios quando o sistema é desenvolvido com êxito e diferentes riscos caso o trabalho de desenvolvimento fracasse. FLUXO DE MODELAGEM DE NEGÓCIO As metas da modelagem de negócio são: Entender a estrutura dinâmica da organização na qual um sistema será distribuído; Entender os problemas atuais na organização alvo e identificar potenciais melhorias; Assegurar que clientes, usuários finais e desenvolvedores tenham um entendimento comum da organização alvo;e Derivar os requisitos de sistema necessários para o suporte da organização alvo. 7 de 18

8 ETAPAS DA ENGENHARIA DE REQUISITOS SOMMERVILLE PRESSMAN Estudo de Viabilidade Elicitação e Análise Obtenção Classificação e Organização Concepção Levantamento Elaboração Negociação Priorização e Negociação Documentação de Requisitos Especificação Validação Gestão Especificação Validação Gestão CASOS DE USO O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que será projetado. Pode-se dizer que um caso de uso é um documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo. Diagrama de caso de uso. 8 de 18

9 ANÁLISE E PROJETO DE SOFTWARE ANÁLISE A fase de análise de requisitos, no contexto do desenvolvimento de um sistema, é aquela na qual são construídos modelos para representar o sistema a ser construído. Esta fase tem como característica não levar com conta o ambiente tecnológico a ser utilizado. Nesta atividade, o foco de interesse é tentar construir uma estratégia de solução sem se preocupar com a maneira como essa estratégia será realizada. Em resumo, a prioridade é saber o que o sistema proposto deve fazer, para, posteriormente (no projeto), definir como o sistema irá fazê-lo. A modelagem de requisitos possui duas visões clássicas: a análise estruturada e a análise orientada a objetos. A análise estruturada considera os dados e os processos que transformam os dados em entidades separadas. Esta técnica descreve o fluxo de informação e transformações que são aplicadas à medida que os dados se movimentam da entrada para a saída. O diagrama que melhor ilustra a análise estruturada é o Diagrama de Fluxo de Dados (DFD), que será visto adiante. A análise orientada a objetos, por sua vez, lança mão da abstração para representar coisas do mundo real, sob a forma de objetos. PROJETO O foco principal da análise são os aspectos lógicos e independentes de implementação de um sistema, ou seja, os requisitos. Na fase de projeto, determina-se o como o sistema funcionará, para atender aos requisitos. A atividade de projeto engloba o conjunto de princípios, conceitos e práticas que conduzem ao desenvolvimento de um sistema ou produto com alta qualidade. Lembro que, lato sensu, este também é o objetivo de todo o processo de desenvolvimento de software. 9 de 18

10 IMPLEMENTAÇÃO, TESTES E IMPLANTAÇÃO IMPLEMENTAÇÃO Na implementação, o sistema é codificado, ou seja, ocorre a tradução da descrição computacional obtida na fase de projeto em código executável, mediante o uso de uma ou mais linguagens de programação. Ao codificar um software, um programador poderá escrever código novo, ou reaproveitar código já existente. Esse reaproveitamento de código é chamado de reuso de software. O reuso de software pode trazer vários benefícios, como ganho de tempo (o código já está escrito), confiança, redução de risco (o código já foi utilizado com sucesso anteriormente), dentre outros fatores. Por fim, é interessante destacar que a maioria das bibliografias prevê que o teste de unidade acontece na etapa da implementação. O teste de unidade é o teste pontual, realizado pelo programador, que verifica que aquele componente ou módulo que ele desenvolveu realmente faz o que deveria fazer, atendendo às especificações do projeto. Uma vez que o sistema esteja codificado (e com seus módulos testados, a nível unidade), os códigos desenvolvidos pelos diversos programadores é 10 de 18

11 integrado, e poderá ser submetido a uma bateria maior e mais complexa de testes. TESTES Teste de software é uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construído. Pode ser planejado antecipadamente e conduzido sistematicamente. Ainda, podem ser testes de baixo nível, no qual são verificados se pequenos segmentos de código-fonte foram corretamente implementados, bem como testes de alto nível, que validam as principais funções do sistema com base nos requisitos do cliente. Estratégias de teste de software Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica (estamos construindo o produto corretamente?), enquanto a Validação se certifica que o software construído corresponde aos requisitos do cliente (estamos construindo o produto certo?). O teste proporciona o último elemento a partir do qual a qualidade pode ser estimada, e, mais pragmaticamente, os erros podem ser descobertos. Conforme afirmado desde o início, a qualidade é incorporada ao software ao longo do processo de engenharia de software. Portanto, a motivação, por trás do teste, é a confirmação da qualidade. Se a qualidade não estiver lá antes do teste, não estará lá após a realização dele. Estratégia de teste de software. Fonte: Pressman, de 18

12 Teste de unidade se concentra em cada unidade: componente, classe ou módulo. Usa intensamente técnicas de teste com caminhos distintos, com o objetivo de descobrir erros dentro do módulo testado. Teste de integração técnica sistemática para construir a arquitetura do software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces (comunicação entre os módulos, não confundir com interface com o usuário). A integração pode ocorrer de forma descendente (top-down) ou ascendente (bottom-up). Integração de módulos. No exemplo, M4 e M7 serão incorporados à arquitetura, e o sistema deverá ser testado com a presença desses dois novos módulos. Teste de validação a validação de software é conseguida por meio de uma série de testes que demonstram conformidade com os requisitos. Um plano de testes poderá definir casos de teste específicos que atestem que os requisitos funcionais sejam satisfeitos, que os requisitos de desempenho sejam atendidos, que a documentação esteja correta, dentre outros. Desvios ou erros descobertos nesse estágio raramente podem ser corrigidos antes do prazo de entrega programado. Se um software é desenvolvido como um produto para ser usado por muitos clientes, é impraticável que todos eles realizem testes formais de aceitação. Muitos construtores de software, então, usam um processo chamado de teste alfa e beta para descobrir erros que apenas o usuário final é capaz de encontrar. O teste alfa é conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. Nele, o desenvolvedor monitora os usuários, registrando os erros e os problemas de uso. O teste beta é conduzido nas instalações dos usuários finais. Via de regra, o desenvolvedor não está presente, e os erros e problemas encontrados são reportados pelos usuários. Teste de sistema o teste de sistema extrapola os limites da engenharia de software. Uma vez validado, o software deverá ser combinado com outros 12 de 18

13 elementos do sistemas (como hardware, pessoas, base de dados). Ele verifica se todos os elementos se combinam corretamente e se a função/desempenho global do sistema é conseguida. Podem ser: Teste de recuperação: força o sistema a falhar de várias formas e verifica se a recuperação é executada corretamente; Teste de segurança: verifica se os mecanismos de proteção incorporados ao sistema protegem contra acesso indevido; Teste de esforço: coloca o programa em condições anormais. Até onde podemos forçar o sistema até que ele falhe? Teste de desempenho: testar o desempenho, em tempo de execução, do software em um contexto de sistema integrado. Pode ser feito em conjunto com testes de esforço; Teste de disponibilização: exercitar o software em cada ambiente no qual ele deve operar, como em vários sistemas operacionais, vários navegadores web, ou várias plataformas (PC, smartphone...). Depuração Quando um erro é encontrado, o código deverá ser futucado para encontrar o pedaço de código que está escrito de maneira incorreta, para então ser corrigido. A esta etapa é dada o nome de depuração. Depurar o código não é testar o código, mas são processos que se relacionam. Técnicas de teste de software O objetivo do teste é encontrar erros, e um bom este: Alta probabilidade de encontrar erros; Não ser redundante; O melhor de uma categoria (o mais completo de um grupo similar de testes);e Nem muito simples, nem muito complexo. Caixa-Branca - Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de caminho básico, teste de ciclos, teste de caminhos lógicos, códigos nunca executados, teste de estrutura de controle. 13 de 18

14 Caixa-Preta - Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação. IMPLANTAÇÃO Na implantação, o sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos, os arquivos são carregados, os dados são importados para o sistema, e os usuários são treinados para utilizar o sistema corretamente. Dependendo da situação, pode ocorrer também a migração de sistemas de do software e de dados preexistentes. PAPÉIS E RESPONSABILIDADES EM PROJETOS DE SOFTWARE Patrocinador O patrocinador do projeto, via de regra, é alguém do alto escalão de uma organização, que compra a idéia do software. Em virtude de sua posição, é capaz de atribuir recursos e dinheiro ao projeto. Durante o ciclo de vida do projeto, o patrocinador atua como um decisor acima do gerente de projeto, podendo tomar decisões fora da alçada do gerente do projeto. Além disso, o patrocinador funciona como um ponto focal para a alta administração e também para outros stakeholders, eventualmente. Um bom patrocinador é a ligação entre o gerente de projeto e gerentes seniores e executa diferentes funções durante o ciclo de vida do projeto, promover e proteger o projeto. Durante o início de um projeto, o patrocinador deve ser responsável pelo Termo de Abertura do Projeto e seu Business Case, alinhando os objetivos do projeto à estratégia corporativa. O patrocinador irá designar um gerente para o projeto, que pode ajudar neste planejamento inicial. 14 de 18

15 Finalmente, é o patrocinador o responsável pelo projeto perante a organização e à alta administração. Ele deve assegurar que os benefícios do projeto estão sendo entregues. Gerente de Projetos O gerente de projetos é o responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Deve fazer o orçamento do projeto de desenvolvimento, estimar o tempo necessário para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma de execução das atividades, a equipe de desenvolvimento, os recursos de hardware e software, etc. Segundo Pressman, o gerente de projeto, ao gerenciar efetivamente o projeto de software, deve focar em 4Ps, e nessa sequência: Pessoas, Produto, Processo e Projeto. Pessoas O gerente de projeto deve ater-se a algumas práticas-chaves, como: formar a equipe, liderar sua equipe, estabelecer boa comunicação com a equipe e com os interessados no projeto. Produto O gerente de projeto também deve analisar detalhadamente os requisitos (junto com os analistas de requisitos), para estabelecer e delimitar o escopo, de modo a poder estimar recursos e prazo. Processo A equipe de software deve ser flexível ao escolher o processo de software mais adequado ao projeto e às tarefas de engenharia de software que fazem parte do modelo selecionado. Projeto 15 de 18

16 É a abordagem de cuidar do projeto como um projeto em si, entendendo fatores críticos de sucesso, planejando, monitorando e controlando o projeto, por meio de métricas e ferramentas. Área de Negócio A área de negócio é o conjunto de stakeholders que será o principal beneficiado pelo projeto de software. Cabe a ela colaborar com a elicitação de requisitos, participar dos testes finais do software, e fornecer o feedback após a sua implantação. Pode-se destacar um personagem nesse contexto, o Especialista de Domínio. O especialista do domínio interage com o analista de requisitos para levantar os requisitos do sistema. Analista de Requisitos O analista de requisitos é o profissional que precisa ter conhecimento do domínio do negócio. Ele precisa compreender tal domínio para definir os requisitos do sistema a ser desenvolvido. O analista de requisitos precisará captar as necessidades dos clientes e repassar esse entendimento aos demais desenvolvedores do sistema, fazendo uma ponte entre os profissionais da computação e os profissionais do negócio. Em suma, os analistas de requisitos realizam o levantamento e a análise de requisitos. Inclusive, enxerga-se como uma progressão natural na carreira dos analistas de requisitos a gerência de projetos, uma vez que os analistas de requisitos adquirem experiência com a participação em diversos projetos. Equipe de desenvolvimento A equipe de desenvolvimento é fortemente atuante nas fases de projeto e implementação da solução de software. Destaque para: Projetistas: avaliam as alternativas de solução do problema resultante da análise e geram a especificação de uma solução computacional detalhada. Podem ser especializados em interface, redes, bancos de dados, etc; Arquitetos de software: especialista em elaborar a arquitetura do sistema como um todo; Programadores: codificação do sistema e testes; 16 de 18

17 Equipe de sustentação A sustentação consiste no suporte e atendimento ao cliente, responsável por manter o produto. Logo, a equipe de sustentação é aquela responsável pela manutenção do sistema após a sua entrega. Dentre os integrantes da equipe de sustentação, destaca-se o analista de suporte, profissional capaz de interpretar a solicitação do cliente e analisar se o problema relatado é um defeito a ser corrigido no sistema ou não. METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE As metodologias ágeis surgiram como um esforço para sanar fraquezas reais e perceptíveis da engenharia de software tradicional. Entretanto, ela não pode ser aplicada a todos os projetos, produtos, pessoas e situações. Quatro são os valores percebidos pela filosofia ágil: Indivíduos e interações, em vez de processos e ferramentas Software funcional, em vez de documentação abrangente Colaboração do cliente, em vez de negociação de contratos Responder mudanças, em vez de seguir um plano Seguidos esses princípios, existem algumas metodologias ágeis bastante conhecidas, como o XP e o Scrum. Vejamos: XP, oriunda de extreme Programming, é uma filosofia de programação que segue algumas práticas genéricas, cujo conhecimento considero válido. São elas: Jogo de Planejamento Pequenas Versões Metáfora Projeto Simples Time Coeso Testes de Aceitação Ritmo Sustentável Reuniões em pé Posse Coletiva Programação em Pares Padrões de Codificação Desenvolvimento Orientado a Testes 17 de 18

18 Refatoração Integração Contínua O Scrum é uma metodologia de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. O Scrum é um conjunto de passos que contém grupos de práticas e papéis pré-definidos. Os únicos papéis são: 1. O Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio; 2. o Scrum Master, que mantém os processos (normalmente no lugar de um gerente de projeto); 3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto, implementação, teste, etc. Sprint Um sprint é a unidade básica de desenvolvimento em Scrum. Sprints tendem a durar entre uma semana e um mês, e são um esforço dentro de uma "caixa de tempo" (ou seja, restrito a uma duração específica) de comprimento constante. Idéias relacionadas: Product Backlog Sprint backlog Planejamento de sprint Daily Scrum Reunião de Planejamento da Sprint (Sprint Planning Meeting) Reunião de Revisão da Sprint (Sprint Review) Retrospectiva da Sprint (Sprint Retrospective) Boa prova! 18 de 18