Prévia do material em texto
PROJETO DE DESENVOLVIMENTO DE SISTEMAS CCT0462 Gregori de Arruda Moreira Desenvolvimento de software é o processo de tomada de um conjunto de requisitos de um usuário (o enunciado do problema), analisá-los, projetar uma solução, e então implementa-la em um computador. O desenvolvimento de software é um estreitamento do foco da engenharia de software no que diz respeito à criação do software real. E é uma ampliação do foco da programação que inclui questões de análise, projeto e implantação funcional. Ciclo de Vida Concepção A fase de planejamento é o processo fundamental de compreensão por que um sistema de informação deve ser construído e determinar como a equipe do projeto o construirá. Esta é uma fase de análise e investigação, onde se respondem as perguntas: • qual o perfil do usuário? • o que o sistema irá fazer? • onde e quando será utilizado? Durante esta fase, a equipe do projeto: * investiga algum sistema atual(is); • identifica oportunidades de melhoria; • e desenvolve um conceito para o novo sistema. Levantameto, Exploração, Modelagem A fase de projeto decide como o sistema irá operar, em termos de: hardware, software e infra-estrutura de rede; a interface de usuário, formulários e relatórios; os programas específicos, bancos de dados e arquivos que serão necessários. Projeto A produção deve garantir a execução bem sucedida de todos os aspectos de desempenho de sistemas. Durante a produção, há a necessidade de se estabelecer como os problemas serão atendidos, que o pessoal de apoio estará disponível, e quando e como as perguntas serão respondidas e resolvidas. Este componente de produção pode iniciar novos ciclos de desenvolvimento e testes por causa de necessidades de redesenho. Codificação e Depuração O sistema é construído e testado para garantir que funcione como projetado. O teste é um dos passos mais críticos na implementação. A maioria das organizações leva mais tempo e atenção ao teste do que para escrever os programas. Testes A instalação é o processo pelo qual o antigo sistema é desligado (caso exista) e o novo é ativado. Instalação Pode incluir três abordagens de transição: • Direta: o novo sistema substitui imediatamente o sistema antigo; • Conversão paralelo: ambos os sistemas, o antigos e o novo são operados por um ou dois meses até que seja evidente que não existam erros no sistema novo; • Conversão escalonada: o novo sistema é instalado em uma parte da organização como um ensaio inicial e depois, gradualmente, instalado em outros. Um dos aspectos mais importantes de conversão é o desenvolvimento de um plano de treinamento para ensinar os usuários utilizarem o novo sistema e ajudar a gerenciar as mudanças provocadas pelo novo sistema. Instalação A equipe de analistas estabelece um plano de suporte ao sistema. Este plano geralmente inclui uma revisão formal ou informal de pós-implementação, bem como uma maneira sistemática para identificar as alterações maiores e menores necessárias para o sistema. Manutenção, Operação e Evolução Aposentadoria Concepção Levantamento Projeto Codificação Testes Instalação Manutenção, Operação e Evolução Aposentadoria Ciclo de Vida do software Questão 1: Liste as fases principais do ciclo de vida de desenvolvimento de sistemas (CVDS) e as suas características. Um modelo de processo de software deve ser escolhido com base: Nos controles e produtos que precisam ser entregues Na natureza do projeto e da aplicação; Nos métodos e ferramentas a serem utilizados; Principais Modelos de Processos Modelo em Cascata Sistemático e seqüencial Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção Base para os outros Modelo em Cascata Problemas O mais antigo e amplamente usado. Projetos reais raramente seguem o fluxo seqüencial que ele propõe. Ocorrem iterações que trazem problemas na aplicação do paradigma. É difícil para o cliente declarar todas as exigências explicitamente. É difícil acomodar as incertezas naturais que existem no começo de muitos projetos. Modelo em Cascata Modelo em Cascata Problemas: O cliente deve ter paciência. Uma versão do software só estará disponível em um ponto tardio do cronograma. Um erro crasso, pode ser desastroso. Desenvolvedores Ociosos. Só é apropriado quando os requisitos são bem conhecidos. Modelo de Prototipação Modelo de Prototipação Modelo de Prototipação Modelo de Prototipação Modelo de Prototipação Modelo de Incremental Modelo Incremental Modelo Incremental Modelo Espiral Modelo Espiral Modelo Espiral Modelo Espiral Modelo Cascata Modelo de Prototipação Modelo em Espiral RUP RUP RUP RUP OpenUP OpenUP é um processo para o desenvolvimento de produtos de software que agrega muitos conceitos do RUP e adiciona valor e práticas ágeis principalmente de metodologias como o XP e o Scrum. OpenUP O OpenUP é baseado em 4 princípios básicos que são: • Colaborar para alinhar interesses e compartilhar conhecimento; • Focar na articulação da arquitetura; • Balancear prioridades concorrentes com o retorno de valor para o Stakeholder; • Envolvimento continuo para obtenção de feedback e melhorias. Tal modelo se propõe a entregar software com o mínimo de formalismo e artefatos gerados. Algumas questões que diferenciam o OpenUp do RUP: - menor quantidade e formalidade de produtos de trabalho; - conceito de micro incrementos que representa a execução de uma pequena unidade do trabalho (work item) e deve ser bem definido para que a equipe possa controlar e monitorar o progresso diário. - é um processo não padronizado que permite que trabalhos complexos sejam gerenciados com mais agilidade e facilidade usando o conceito auto-organização do time de projeto. - realiza reuniões rápidas diárias (Scrum Daily meetings) para que a equipe inteira do projeto possa compreender o que os outros membros já realizaram e assim, remover possíveis barreiras planejando o que será feito até a próxima reunião. OpenUP OpenUP - As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. - No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. - As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. - A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. - Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. - Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. SCRUM Seleção de Projeto de Sistemas “Vivemos em um país reconhecido mundialmente como o campeão da burocracia governamental, o que acaba gerando um lastro de ineficiência operacional em várias camadas da sociedade, especialmente no segundo setor. Esse burocrático e inóspito ambiente exige das organizações processos internos que acelerem o tempo de resposta ao mercado e as mantenham competitivas. Esse desafio da busca pela desburocratização é exatamente o pilar central do Project Model Canvas, modelo de planejamento ágil deprojetos idealizado pelo brasileiro José Finocchio Jr. José Finocchio Jr. O objetivo deste modelo é representar de forma visual e em apenas uma folha chamada Canvas (“tela”, em inglês) treze componentes fundamentais para a composição do plano do projeto. Durante a construção do Canvas é imprescindível que o facilitador tenha sólidos conhecimentos e experiência em gerenciamento de projetos. Além disso, é desejável que crie um ambiente confortável para que os envolvidos na criação do plano contribuam em um processo estruturado de brainstorming, coordenado de forma visual, para que se promova a criatividade e a colaboração Gerenciamento de Projetos É um empreendimento temporário realizado para criar um produto, serviço ou resultado distinto. O que é um Projeto? Aspectos de um Projeto? - Temporário: todo projeto tem um início e um fim. A duração é sempre finita, ainda que possa ser longa. O resultado de um projeto pode ser duradouro, mas a oportunidade de sua realização e a equipe que nele trabalha também são geralmente de natureza temporária . - Geração de produtos, serviços ou resultados distintos: cada projeto resulta em uma entrega singular, distinta de outras entregas. - Elaboração progressiva: projetos são realizados por etapas, de forma incremental. - Escopo do produto: o conjunto das características que descrevem um produto, serviço ou resultado. - Escopo do projeto: o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas. No desenvolvimento de software, o escopo de um produto é definido por seus requisitos. Portanto, a definição final do escopo de um produto,, é o Modelo do problema, ou a Especificação dos requisitos, dele derivada. Como a própria produção desse artefato requer a execução de um conjunto de atividades que podem ser complexas, é preciso dispor de um artefato de partida, pelo menos para o planejamento inicial. Levantamento de Requisitos Requisito é simplesmente uma declaração do que o sistema deve fazer ou de quais características ele precisa possuir. A análise dos requisitos do sistema é necessária para a aceitação da proposta do sistema. Sendo assim, é importante que o cliente apresente suas necessidades ou demandas, que todas as pessoas envolvidas conheçam os objetivos do projeto. REQUISITOS DE NEGÓCIO Definem os objetivos gerais do sistema e esclarecem as contribuições que o sistema fará ao sucesso da organização Desenvolver produtos conforme a necessidade do usuário; Economizar tempo e dinheiro; Entender as necessidades do cliente; Comparar o que você esta entregando com a necessidade do cliente; REQUISITOS FUNCIONAIS Um requisito funcional está diretamente relacionado a um processo que o sistema precisa realizar como parte do suporte fornecido a uma tarefa do usuário e/ou à informação que o sistema precisa fornecer quando o usuário estiver realizando uma tarefa. REQUISITOS NÃO FUNCIONAIS São os atributos de qualidade, as restrições de design e implementação e as interfaces externas que um produto deve possuir. Essa categoria de requisitos inclui importantes propriedades comportamentais que o sistema deve ter, tais como desempenho e usabilidade. Ex: A habilidade de acessar o sistema por meio de um dispositivo móvel seria considerada um requisito não funcional. Esses requisitos são usados principalmente na fase de design, quando são tomadas decisões sobre a interface com o usuário, o hardware e o software e a arquitetura básica do sistema. Entretanto, muitos desses requisitos serão descobertos durante os diálogos com os usuários na fase de análise e devem ser registrados quando forem descobertos. Técnicas de Obtenção de Requisitos Conduzir uma sessão de brainstorming; Entrevistar usuários; Enviar questionários; Trabalhar no ambiente alvo; Estudar sistemas semelhantes; Examinar sugestões e relatórios de problemas; Conversar com equipes de suporte; Estudar melhorias feitas pelos usuários; Conduzir workshops; Análise de Requisitos Coletamos os requisitos e agora? A FASE DE ANÁLISE A fase de análise é chamada assim porque o termo análise se refere a dividir um todo em suas partes, com a intenção de entender a natureza, a função e os inter-relacionamentos dessas mesmas partes. O processo básico de análise envolve três etapas: - Entender a situação existente (sistema no estado em que se encontra atualmente); - Identificar as melhorias; - Definir os requisitos do novo sistema (o sistema futuro); Análise de Documentos As equipes de projeto usam frequentemente a análise de documentos para compreender o sistema atual existente. Em condições ideais, a equipe de projeto que o desenvolveu produziu uma documentação, que foi, em seguida, atualizada para todos os projetos subsequentes. Nesse caso, a equipe de projeto pode começar revendo a documentação e examinando o próprio sistema. Observação A observação, o ato de verificar atentamente processos em execução, é uma ferramenta poderosa para obter uma noção sobre o sistema existente. Ela permite ao analista ver a realidade de uma situação, em vez de escutar outras pessoas descrevê-la em entrevistas. Diversos estudos de pesquisas têm mostrado que, na realidade, muitos gerentes não se lembram da forma como trabalham e alocam seu tempo. Análise do Problema A estratégia de análise de requisitos mais simples (e provavelmente a mais usada em geral) é a análise do problema. A análise do problema significa pedir aos usuários e gerentes que identifiquem os problemas com o sistema atual existente e descrevam como resolvê-los no sistema futuro. A maioria dos usuários tem uma boa ideia das modificações que gostariam de ver, e a maior parte deles estará bastante disponível para sugeri-las. A maioria das modificações tende a resolver os problemas em vez de aproveitar as oportunidades, mas isso também é possível. As melhorias da análise dos problemas tendem a ser pequenas e incrementais (por exemplo, adicionar um campo para armazenar o telefone celular do cliente, fornecer um novo relatório que não existe atualmente). Análise da Causa Principal (Causa Raiz) As ideias produzidas pela análise do problema tendem a ser soluções para os problemas. Todas as soluções adotam hipóteses sobre a natureza do problema, hipóteses que podem ou não ser válidas. De acordo com nossa experiência, os usuários (e a maioria das pessoas em geral) tendem a adotar rápido as soluções sem considerar completamente a natureza do problema. Algumas vezes as soluções são apropriadas, mas muitas vezes eles tratam de um sintoma do problema, e não do problema real ou propriamente da causa raiz (causa principal). Análise da Duração A análise da duração exige um exame detalhado da quantidade de tempo necessária para realizar cada processo no sistema atual existente. Os analistas começam determinando a quantidade total de tempo que levam, em média, para realizar um conjunto de processos do negócio para uma determinada entrada. Assim, eles medem o tempo de cada etapa isolada (ou de cada subprocesso) no processo do negócio. Análise Comparativa (Benchmarking Informal) A análise comparativa ou benchmarking se refere ao estudo de como as organizações realizam um processo de negócio a fim de aprender de que forma sua organização pode fazer algo melhor. O benchmarking ajuda a organização introduzindo ideias que os funcionários podem nunca ter levado em consideração, mas que possuam o potencial de agregar valor. Análise de Resultados A análise de resultados concentra-se no entendimentodos resultados fundamentais que fornecem valor aos clientes. Embora esses resultados pareçam óbvios, frequentemente não o são. Por exemplo, suponha que você esteja em uma companhia de seguros, e um de seus clientes acabou de sofrer um acidente de carro. Qual é o resultado fundamental sob a perspectiva do cliente? Tradicionalmente, as companhias de seguro respondem a essa pergunta admitindo que o cliente deseje receber rápido o pagamento do seguro. Entretanto, para o cliente, o pagamento é apenas um meio para o resultado real: um carro consertado. A companhia de seguros pode se beneficiar por ampliar sua visão do processo do negócio além de suas fronteiras tradicionais afim de incluir não apenas o pagamento dos reparos, como também realizar os reparos ou contratar uma oficina autorizada para fazer isso. Análise de Tecnologia Muitas modificações importantes nos negócios, ao longo da última década, foram possibilitadas por novas tecnologias. Portanto, a análise de tecnologia inicia com os analistas e os gerentes desenvolvendo uma lista de tecnologias importantes e interessantes. Então, o grupo identifica sistematicamente como cada uma das tecnologias poderia ser aplicada ao processo do negócio e identifica como o negócio poderia se beneficiar delas. Design do Sistema TRANSIÇÃO DOS REQUISITOS PARA O DESIGN A finalidade da fase de análise é compreender quais são as necessidades do negócio, e decidir como construí-las é a finalidade da fase de projeto. O design do sistema é a determinação da arquitetura global do sistema, trata-se de um conjunto de componentes físicos de processamento, hardware, software, pessoas e a comunicação entre eles, que satisfará os requisitos essenciais do sistema. Durante a parte inicial do design, a equipe de projeto converte os requisitos do negócio em requisitos do sistema, que descrevem os detalhes técnicos para a construção dos mesmos. Diferente dos requisitos do negócio, que são listados na definição de requisitos e transmitidos por meio de diagramas, canvas, histórias de usuário, casos de uso, modelos de dados e de processos lógicos, os requisitos do sistema são transmitidos fazendo uso de um grupo de documentos de design e modelos de dados e de processos físicos. Juntos, os documentos de design e os modelos físicos constituem o projeto gráfico do novo sistema. DESIGN DE ARQUITETURA Os componentes arquitetônicos mais importantes de qualquer sistema são o software e o hardware. Os componentes de software mais importantes do sistema em desenvolvimento precisam ser identificados e, em seguida, alocados aos vários componentes de hardware nos quais o sistema será executado. Cada um desses componentes pode ser combinado de muitas maneiras diferentes. Todos os sistemas de software podem ser divididos em quatro funções básicas : • Armazenagem de Dados; • Lógica de Acesso aos Dados; • Lógica de Aplicação; • Lógica de Apresentação; • A primeira é a armazenagem de dados. A maioria dos sistemas de informações requer que os dados sejam armazenados e recuperados, seja em um pequeno arquivo, como uma lista de produtos químicos não mais autorizados para aplicações residenciais, seja em um grande banco de dados que armazena os registros de recursos humanos de uma organização. Essas são as entidades de dados documentadas nos DER (Diagrama Entidade Relacionamento). Armazenagem dos Dados Descrever as opções de arquitetura mais recentes, como computação em nuvem (cloud computing): • A nuvem pública é definida como uma série de serviços de computação oferecidos por terceiros à Internet pública, os quais são disponibilizados a qualquer pessoa que queira utilizá-los ou comprá-los. Eles podem ser gratuitos ou vendidos sob demanda, permitindo que os clientes paguem apenas pelo seu consumo de ciclos de CPU, armazenamento ou largura de banda; • Nuvem privada refere-se aos serviços de computação em nuvem oferecidos pela Internet ou por uma rede interna privada somente a usuários selecionados e não ao público geral. Além disso, as nuvens privadas oferecem um maior nível de segurança e privacidade por meio de firewalls; • A nuvem híbrida é um ambiente de computação que combina nuvens públicas e nuvens privadas, permitindo que os dados e aplicativos sejam compartilhados entre elas. Quando a demanda de computação e processamento oscila, a computação em nuvem híbrida proporciona às empresas a capacidade de dimensionar facilmente sua infraestrutura local para a nuvem pública a fim de operar qualquer excesso, sem que datacenters de terceiros tenham acesso aos seus dados integrais. Armazenagem dos Dados • A segunda função é a lógica de acesso aos dados, o processamento exigido para acessar os dados, significando frequentemente consultas a banco de dados em SQL. Lógica de Acesso aos dados • A terceira função é a lógica de aplicação; a lógica documentada nos diagramas de fluxo de dados (DFDs), casos de uso, histórias de usuários e requisitos funcionais. Lógica de Aplicação o A segurança é a capacidade de proteger o sistema de informações contra interrupções e perda de dados, causados por uma ação intencional (por exemplo, um hacker ou um ataque terrorista) ou um acontecimento aleatório. o Os requisitos culturais e políticos são específicos para os países onde o sistema será usado. No ambiente empresarial globalizado de hoje as empresas estão expandindo seus sistemas para atingir usuários em todo o mundo. Lógica de Aplicação • A quarta função é a lógica de apresentação: a exibição das informações para o usuário e a aceitação dos comandos do usuário (a interface com o usuário). Lógica de Apresentação DESIGN DA INTERFACE COM O USUÁRIO O design da interface é o processo de definição de como o sistema interagirá com as entidades externas (clientes, fornecedores e outros sistemas). Você deve entender que o design da interface com o usuário define a maneira como os usuários interagirão com o sistema e a natureza das entradas e saídas que o sistema aceita e produz. A interface com o usuário inclui três partes fundamentais. • A primeira é o mecanismo de navegação, a maneira pela qual os usuários fornecem instruções ao sistema e informam a ele o que fazer (p.ex., botões, menus). • A segunda é o mecanismo de entrada, a maneira como o sistema captura as informações (p.ex., formulários para adicionar novos clientes). • A terceira é o mecanismo de saída, a maneira pela qual o sistema fornece informações ao usuário ou a outros sistemas (p.ex., relatórios, páginas Web). Lógica de Apresentação O objetivo é tornar a interface agradável aos olhos e simples de usar e, ao mesmo tempo, minimizar os esforços que os usuários despendem para realizar suas tarefas. O sistema nunca é um fim por si só; ele é simplesmente um meio de realizar o negócio da empresa. Lógica de Apresentação Lógica de Apresentação Lógica de Apresentação Obrigado!
