Analise e Desenvolvimento de s

CENTRO UNIVERSITÁRIO LEONARDO DA VINCI Rodovia BR 470, Km 71, nº 1.040, Bairro Benedito 89130-000 - INDAIAL/SC www.uniasselvi.com.br

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EM FOCO UNIASSELVI 2016 Organização Greisse Moser Badalotti Autoria Edemilson Bay Elton Giovani Gretter Greisse Moser Badalotti Neli Miglioli Sabadin Pedro Sidnei Zanchett Simone Cristina Aléssio Reitor da Uniasselvi Prof. Hermínio Kloch Pró-Reitora de Ensino de Graduação a Distância Prof.ª Francieli Stano Torres Pró-Reitor Operacional de Graduação a Distância Prof. Hermínio Kloch Editor-Chefe Prof. Evandro André de Souza Diagramação e capa Djenifer Luana Kloehn Revisão Final Joice Carneiro Werlang José Roberto Rodrigues Propriedade do Centro Universitário Leonardo da Vinci

Análise e desenvolvimento de sistemas em Foco

Ficha catalográfica Elaborada na fonte pela Biblioteca Dante Alighieri – UNIASSELVI – Indaial.

005.102 B356a Moser; Greisse Análise e desenvolvimento de sistemas em foco/ Greisse Moser; Neli Miglioli Sabadin; Pedro Zanchett (Orgs.) : UNIASSELVI, 2016. 144 p. : il. ISBN 978-85-7830-988-6

1.Engenharia de software. I. Centro Universitário Leonardo Da Vinci.

Análise e desenvolvimento de sistemas em Foco

Análise e desenvolvimento de sistemas em Foco

PREFÁCIO Caro leitor, você está prestes a iniciar a leitura do livro Análise e Desenvolvimento de Sistemas em Foco I, que apresentamos a você com grande satisfação. O presente livro envolve assuntos vinculados à área de atuação do analista e desenvolvedor de sistemas. O objetivo é explorar temas que permitam instigá-lo sobre os diversos assuntos aqui tratados, fazendo conexões pertinentes ao contexto tecnológico. Constantemente somos avaliados em provas, concursos e, em grande parte, precisamos de um guia rápido para nos apoiar na revisão dos conhecimentos adquiridos no decorrer do curso. Com base nesta necessidade, consideramos de extrema importância a revisão dos assuntos e, como resultado, prepará-lo ainda mais para obter o sucesso nestas atividades. Vale salientar que os textos reunidos nesta publicação são frutos das problematizações e estudos realizados pela equipe de professores, e organizados pela coordenadora do Curso de Análise e Desenvolvimento de Sistemas da UNIASSELVI, pois o mesmo reflete a base conceitual da profissão. Esperamos que você faça uma ótima leitura! Me. Greisse Moser Badalotti Coordenadora do Curso Superior de Análise e Desenvolvimento de Sistemas

Análise e desenvolvimento de sistemas em Foco

Análise e desenvolvimento de sistemas em Foco

SUMÁRIO TÓPICO 1 - INTRODUÇÃO À ENGENHARIA DE SOFTWARE ..................... 1 INTRODUÇÃO .............................................................................................. 2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS ..................... 2.1 RUP ............................................................................................................ 3 FASES DE DESENVOLVIMENTO DE SOFTWARE .................................... 4 PROCESSOS DE ENGENHARIA DE SOFTWARE ..................................... 5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE ...................... 6 REQUISITO DE SOFTWARE ....................................................................... 7 ESTIMATIVAS E MÉTRICAS DE PROJETOS DE SOFTWARE .................. 8 QUALIDADE DE SOFTWARE ...................................................................... 9 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE ..... 10 MÉTODOS ÁGEIS ...................................................................................... 10.1 SCRUM .................................................................................................... 10.2 EXTREME PROGRAMMING ................................................................... 11 TESTES DE SOFTWARE ...........................................................................

1 1 3 4 4 5 5 7 7 12 16 19 20 22 23

TÓPICO 2 - PROGRAMAÇÃO ORIENTADA A OBJETOS ............................. 1 CONCEITOS DA PROGRAMAÇÃO ORIENTADA A OBJETOS ................. 2 PROJETO ORIENTADO A OBJETOS .......................................................... 3 OBJETIVOS DA MODELAGEM ................................................................... 4 VANTAGENS DO PROJETO OO ................................................................. 5 DIAGRAMAS ESTRUTURAIS ...................................................................... 6 DIAGRAMAS COMPORTAMENTAIS ........................................................... 7 PADRÃO DE PROJETOS ............................................................................. 8 VANTAGENS DO USO DE PADRÕES ......................................................... 9 OS PADRÕES MAIS UTILIZADOS ..............................................................

27 27 30 31 31 32 33 33 34 37

TÓPICO 3 - LÓGICA, ALGORITMOS E ESTRUTURA DE DADOS ............... 1 LÓGICA DE PROGRAMAÇÃO .................................................................... 1.1 ESTRUTURAS DE SELEÇÃO .................................................................. 1.1.1 “Se-então-senão” ................................................................................... 1.1.2 Seleção Encadeada ...............................................................................

39 39 40 41 42

Análise e desenvolvimento de sistemas em Foco

1.2 ESTRUTURAS DE REPETIÇÃO ............................................................... 1.2.1 Enquanto-faça ......................................................................................... 1.2.2 Para-faça ................................................................................................. 1.2.3 Repita-até ................................................................................................ 1.3 VETORES UNIDIMENSIONAIS ................................................................. 1.4 MATRIZES .................................................................................................. 1.5 LISTAS ENCADEADAS .............................................................................. 1.6 PILHAS ....................................................................................................... 1.7 FILAS ......................................................................................................... 1.8 ANÁLISE E TÉCNICAS DE ALGORITMOS ............................................... 1.8.1 Divisão e Conquista ................................................................................ 1.8.2 Método Guloso ........................................................................................ 1.8.3 Programação Dinâmica ...........................................................................

44 44 45 46 46 48 50 52 54 55 55 57 60

TÓPICO 4 - BANCO DE DADOS RELACIONAL ........................................... 1 INTRODUÇÃO AO BANCO DE DADOS RELACIONAL ............................. 2 CONCEITOS DO MODELO ENTIDADE-RELACIONAMENTO ................... 3 CARDINALIDADE DE RELACIONAMENTOS ............................................. 4 GRAUS DE RELACIONAMENTOS .............................................................. 5 TIPOS DE ENTIDADES ................................................................................ 6 PADRÃO SQL PARA BANCO DE DADOS RELACIONAL ......................... 7 SELECIONANDO DADOS: DQL - DATA QUERY LANGUAGE .................. 8 FUNÇÕES EM SQL ...................................................................................... 9 COMBINAÇÃO DE CONSULTAS ................................................................

63 63 67 68 69 71 73 74 77 78

TÓPICO 5 - ARQUITETURA E REDES DE COMPUTADORES ..................... 1 PRINCIPAIS TIPOS DE ARQUITETURAS COMPUTACIONAIS ................. 2 COMPONENTES FÍSICOS DO SISTEMA COMPUTACIONAL ................... 3 TIPOS DE MEMÓRIAS E GERENCIAMENTO ............................................. 4 TIPOS DE REDES ........................................................................................ 5 TOPOLOGIAS DE REDES ........................................................................... 6 ENDEREÇOS IPV4 E IPV6 ........................................................................... 7 SISTEMA DNS ..............................................................................................

81 81 84 90 94 96 97 100

TÓPICO 6 - PROGRAMAÇÃO WEB ............................................................... 103 1 INTRODUÇÃO .............................................................................................. 103

Análise e desenvolvimento de sistemas em Foco

TÓPICO 7 - GESTÃO DE PROJETO .............................................................. 1 INTRODUÇÃO .............................................................................................. 2 PARTES INTERESSADAS E PMO .............................................................. 3 OS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS ..... 4 ÁREAS DE CONHECIMENTO ..................................................................... 5 ESCOPO ....................................................................................................... 6 TEMPO .......................................................................................................... 7 CUSTO .......................................................................................................... 8 QUALIDADE ................................................................................................. 9 RECURSOS HUMANOS ............................................................................... 10 COMUNICAÇÕES ....................................................................................... 11 RISCOS ....................................................................................................... 12 AQUISIÇÕES .............................................................................................. 13 GERENCIAMENTO DAS PARTES INTERESSADAS ............................... REFERÊNCIAS ................................................................................................

115 115 117 120 123 125 125 127 127 128 129 130 132 133 135

Análise e desenvolvimento de sistemas em Foco

Análise e desenvolvimento de sistemas em Foco

-------- [ TÓPICO 1 - INTRODUÇÃO À ENGENHARIA DE SOFTWARE ] -------Caro(a) acadêmico(a), neste capítulo vamos relembrar alguns dos principais conceitos relacionados aos temas de Engenharia de Software e Qualidade de Software. Apresentaremos esses assuntos de forma sintetizada. Ressaltamos que, em caso de dúvida, você pode buscar o detalhamento do assunto no caderno da disciplina. Apresentaremos um resumo do que consideramos os principais tópicos do tema apresentado, que são: Introdução à Engenharia de Software, Metodologia de Desenvolvimento de Sistemas, RUP, Scrum, Extreme Programming e Testes de Software. Vamos então iniciar os estudos, empregando o máximo de atenção e foco para que os resultados sejam os melhores possíveis, contribuindo para o incremento e fixação dos seus conhecimentos! Prof. Pedro Sidnei Zanchett 1

1 INTRODUÇÃO Segundo Ian Sommerville (2011), a Engenharia de Software é uma disciplina da engenharia de sistemas que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de levantamento e especificação de requisitos até a implantação e manutenção, ou seja, que entrou em operação. É um conjunto de atividades, parcialmente ou totalmente ordenadas, com a finalidade de obter um produto de software de qualidade e cumprir corretamente os contratos de desenvolvimento. Segundo Roger Pressman (2006), a Engenharia de Software poderá ser mais bem entendida como uma tecnologia em camadas ou níveis, conforme pode ser vista na Figura 1.

Análise e desenvolvimento de sistemas em Foco

FIGURA 1 - CAMADAS DA ENGENHARIA DE SOFTWARE

FONTE: Disponível em: . Acesso em: 6 jul. 2015.

Na base da figura, formando a camada foco na qualidade, dá-se ênfase à preocupação de qualquer disciplina de engenharia, que é qualidade. A qualidade na Engenharia de Software é baseada nos conceitos de gerenciamento de qualidade total (TQM – Total Quality Management) para a melhoria contínua dos processos para obter sucesso em longo prazo através da satisfação dos clientes (HIRAMA, 2011). 2

De acordo com Hirama (2011), as camadas são divididas em: A camada de processo permite integrar as camadas de métodos e de ferramentas para que se possa desenvolver um software nos prazos acordados e de maneira adequada. Um processo que permite que se planeje e se controle o projeto de software. A camada de métodos provê as abordagens e as atividades necessárias para a construção de um software. Os métodos abrangem um conjunto amplo de tarefas que incluem análise de requisitos, projeto, implementação, testes e manutenção. Os métodos de Engenharia de Software são baseados em um conjunto de princípios que governam cada área de tecnologia e incluem atividades de modelagem e técnicas descritivas. A camada de ferramentas provê apoio automatizado ou semiautomatizado para processos e métodos. As ferramentas da área de Engenharia de Software são conhecidas como CASE (Engenharia de Software Apoiada por Computador, do termo em inglês Computer-Aided Software Engeneering).

Análise e desenvolvimento de sistemas em Foco

2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS Segundo Fernandes (1999), metodologia de sistemas se define como um conjunto de normas, procedimentos, técnicas e ferramentas de análise que definem o padrão desejado por uma empresa para o desenvolvimento de projetos de sistemas. A ausência de uma metodologia de desenvolvimento de sistemas pode levar ao caos, na medida em que cada indivíduo procura aplicar em seu projeto as melhores soluções dentro das limitações de sua experiência profissional. Mesmo que suas soluções sejam ótimas e que os resultados individuais sejam melhores, dificilmente, no conjunto de todas as aplicações de uma corporação, haverá a harmonia desejada. A produtividade e a eficiência que são esperadas de um departamento de sistemas não podem ser obtidas sem critérios, sem regras e sem análise contínua das ferramentas de trabalho postas à disposição dos profissionais de sistemas (PRESSMAN, 2006). Fernandes (1999) nos diz que, para que uma metodologia de desenvolvimento de sistemas seja consistente, oferecendo maior produtividade e qualidade, deverá atender a alguns requisitos fundamentais: • Padronização: executar as atividades de maneira idêntica, fazendo com que haja aperfeiçoamento do processo. • Flexibilidade: é a capacidade de se adaptar às mudanças. • Documentação: manter informações sobre o produto e garantir rapidez diante das mudanças. • Modularização: consiste em dividir um conjunto de atividades em vários conjuntos menores, objetivando melhor visualização e acompanhamento por parte de todos os interessados no resultado final. • Planejamento: forma madura de administrar o tempo é programar o futuro em relação às metas e aos objetivos a serem alcançados.

Análise e desenvolvimento de sistemas em Foco

3

2.1 RUP Segundo Kroll e Kruchten (2003), o Rational Unified Process, de sigla RUP, é uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. É um processo de engenharia de software bem definido e bem estruturado. Ele define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto, articulando claramente os marcos essenciais e pontos de decisão e, por fim, é também um produto de processo que oferece uma estrutura de processo customizável para a engenharia de software. O RUP utiliza a linguagem de modelagem unificada para especificar, modelar e documentar artefatos. Por ser flexível e configurável, ele pode ser utilizado em projetos de pequeno, médio e grande porte. Com o RUP é possível obter qualidade de software, produtividade no desenvolvimento, operação e manutenção de software, controle sobre o desenvolvimento dentro de custos, prazos e níveis de qualidade desejados, sem deixar de levar em conta a estimativa de prazos e custo com maior precisão (BOENTE, 2016). 4

3 FASES DE DESENVOLVIMENTO DE SOFTWARE Atualmente, muitas são as metodologias de desenvolvimento de softwares. Existem as clássicas (antigas), que são mais estáveis de serem executadas através de diversos ciclos de vida prescritivo, seguindo um único caminho de trabalho, e aquelas metodologias ágeis, que possuem diversas formas dinâmicas de execução, exigindo maior experiência dos envolvidos. Para capturar a dimensão do tempo de um projeto, o processo de Engenharia de Software se divide em quatro fases que indicam a ênfase que é dada no projeto em um dado instante: • • • •

Fase de Iniciação: ênfase no escopo. Fase de Elaboração: ênfase na análise. Fase de Construção: ênfase no desenvolvimento. Fase de Transição: ênfase na implantação.

Análise e desenvolvimento de sistemas em Foco

4 PROCESSOS DE ENGENHARIA DE SOFTWARE No momento em que se decide construir um software, é fundamental também decidir qual processo será seguido. A criação de um projeto de software é uma atividade intelectual de alto nível de complexidade, necessitando melhor visibilidade na sua construção, sabendo-se de início quais são as etapas do projeto. Um processo de software é composto por métodos (aquilo que diz o que, em uma determinada tarefa), por ferramentas (que dão suporte automatizado aos métodos) e procedimentos (que fazem o elo de ligação entre os métodos e as ferramentas). Uma organização que possui um processo de engenharia de software deverá levar muito a sério estes três princípios de processo, a fim de que seus projetos de software sejam de sucesso, ou seja, equipes produtivas e softwares bem feitos.

5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum, determinando os passos a serem seguidos no desenvolvimento de sistemas, mantendo uma padronização de trabalho e determinando as etapas de validação do projeto. As fases do ciclo de vida são constituídas de planejamento (iniciação), análise e especificação de requisitos, projeto (elaboração), implementação (construção), testes, entrega e implantação (transição) e, por fim, operação e manutenção, passando desde a sua concepção até ficar sem uso algum após o término do projeto. De maneira geral, as fases do ciclo de vida de um software são constituídas de planejamento, análise e especificação de requisitos, projeto, implementação, testes, entrega e implantação, operação e manutenção. Os modelos de processo de ciclo de vida durante o desenvolvimento do software podem ser linear, incremental ou iterativo, logo, compreendê-los poderá auxiliar na adoção de um dos modelos mais adequados à realidade e necessidade da organização.

Análise e desenvolvimento de sistemas em Foco

5

Para cada uma destas categorias de ciclos de vida de software há um ou mais modelos formais disponíveis para adoção, e os modelos mais conhecidos são:

6

• Modelo cascata ou sequencial, possui um ciclo de vida clássico, em que todas as fases de desenvolvimento possuem início e fim bem definidos, e não avança sem estar com a fase anterior 100% concluída. • O objetivo das tecnologias de prototipação é produzir uma representação visual das funcionalidades que o sistema terá depois de pronto, permitindo ao usuário e à equipe de desenvolvimento avaliar as características antes que ele seja efetivamente implementado e entregue. Inicialmente, o modelo de prototipação desenvolve uma visão da sua interface e depois reaproveita as telas para configurar e programar o restante do produto de software, trazendo maior rapidez na construção do projeto e aceitação dos usuários. • O modelo espiral traz uma abordagem orientada à gestão de riscos ao invés de apenas orientar a documentação e codificação, como nos casos dos modelos cascata e de prototipação. Também no modelo espiral, à medida que o projeto de software avança, são incorporados novos requisitos de forma evolutiva, com sobreposição de atividades em cada fase do projeto, aumentando a qualidade do planejamento em cada ciclo e dando maior visibilidade à gerência. • O modelo iterativo e incremental permite dividir o escopo do projeto em partes gradativas do desenvolvimento, evoluindo o projeto em versões de novas funcionalidades até o sistema estar completo. O modelo iterativo pode desenvolver os módulos ou funcionalidade de forma independente e liberar o projeto em partes; já o modelo incremental poderá desenvolver em módulos, porém há dependência de funcionalidades entre estes módulos para um próximo módulo ser implementado, permitindo a liberação após o acréscimo de funcionalidades feitas nas iterações anteriores. • O modelo baseado em componentes permite agrupar rotinas relacionadas de forma a montar componentes que podem ser reutilizados em diversos módulos do sistema. A partir do momento em que sobe o requisito do cliente, é feita uma busca na biblioteca de componentes, que trata sobre este requisito, e se já existir e estiver completo, faz-se o seu reúso; caso contrário, criar um novo componente e fazer sua integração à biblioteca, liberando o produto pronto ao cliente. • O foco do modelo em V dá ênfase nas atividades de testes durante a análise, implementação e homologação do sistema, primeiramente validando-os antes do desenvolvimento, garantindo maior entendimento do problema e evitando enganos e retrabalhos.

Análise e desenvolvimento de sistemas em Foco

• Modelo RAD (Rapid Application Development) propõe um ciclo de vida rápido de desenvolvimento utilizando um processo incremental entre as etapas de modelagem e codificação durante um período de até 90 dias. Já o modelo de quarta geração trata dos modelos de última geração, utilizando ferramentas de alto nível através da inteligência computacional, explorando os paradigmas da ontologia e semântica das aplicações, ou seja, próxima à linguagem natural.

6 REQUISITO DE SOFTWARE A partir do momento em que for decidido iniciar um processo de construção de um software, deve-se definir o escopo do projeto através de uma lista de funcionalidades que se deseja disponibilizar para seus usuários no sistema, no qual estas necessidades identificadas são denominadas de requisito. Portanto, requisito é uma definição formal e detalhada de uma função do sistema. A extração de requisitos é o processo de transformar o conhecimento tácito, que está na mente dos usuários, em conhecimento explícito via documentação formal. Essa transformação só é possível através da determinação dos objetivos do produto e das restrições para a sua operacionalidade, através de uma análise do problema e documentação dos resultados. A saída do processo de extração de requisitos é um documento de especificação do sistema que deve dizer o que o produto a ser desenvolvido deverá fazer, e não como deve ser feito. Diversas atividades de requisitos de software ocorrem ao longo de todo o ciclo de vida do software, um trabalho que consiste na análise de requisitos para identificar, quantificar, definir, especificar, documentar, rastrear, priorizar e classificar os principais problemas que o futuro software deve resolver. Existem duas categorias de requisitos: os requisitos de negócio, que irão detalhar quais serviços e restrições são esperados do sistema, e os requisitos de sistemas, que irão detalhar as funções e restrições operacionais do sistema; a primeira atividade executada pelo analista de negócios e, a segunda, pelo analista de sistemas.

Análise e desenvolvimento de sistemas em Foco

7

Os requisitos de negócio ou de sistemas podem ser realizados por três tipos: os requisitos funcionais, que definem o comportamento do sistema; os requisitos não funcionais, que incluem restrições impostas pelas normas ou tecnologias; e os requisitos inversos, que irão informar tudo o que não deverá contemplar no sistema.

7 ESTIMATIVAS E MÉTRICAS DE PROJETOS DE SOFTWARE Estimar software significa determinar quanto de dinheiro, esforço, recursos e tempo serão necessários para criar um sistema, ou seja, o gerente e a equipe de desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, o tempo de duração e, por fim, o custo do projeto.

8

A estimativa de custo faz parte do planejamento de qualquer projeto de engenharia. A diferença é que na engenharia de software o custo principal é o esforço, ou seja, o custo de mão de obra; assim, para se calcular o custo de software é necessário dimensionar o trabalho para desenvolvê-lo. Em geral, esse trabalho é expresso pelo número de pessoas trabalhando numa unidade de tempo, tal como pessoas-mês ou pessoa-ano. O trabalho que uma pessoa consegue fazer num mês pode ser traduzido em números de horas de trabalho num mês. Métricas de Software é um assunto discutido há mais de 20 anos na engenharia de software, e, no entanto, não é verificada sua utilização, na prática, pela grande maioria dos projetos de construção de software. Área que possibilita realizar uma das atividades mais fundamentais do processo de gerenciamento de projetos: o planejamento. A partir desse, pode-se identificar a quantidade de esforço, de custo e das atividades que serão necessárias para a realização do projeto (ZANCHETT, 2015). Ainda segundo o autor, uma métrica de software é a medição de um atributo (propriedades ou características) de uma determinada entidade (produto, processo ou recursos). Como exemplo podemos citar: o tamanho do produto de software em número de linhas de código; número de pessoas necessárias para programar um caso de uso; número de defeitos encontrados por fase de desenvolvimento; esforço para a realização de uma tarefa; tempo para a realização de uma tarefa; custo para a realização de uma tarefa; grau de satisfação do cliente etc.

Análise e desenvolvimento de sistemas em Foco

A partir do uso das métricas de software, uma empresa desenvolvedora de sistemas poderá entender e aperfeiçoar o processo de desenvolvimento, melhorar a gerência de projetos e o relacionamento com clientes, reduzir frustrações e pressões de cronograma, gerenciar contratos de software, indicar a qualidade de um produto de software, avaliar a produtividade do processo, avaliar os benefícios (em termos de produtividade e qualidade) de novos métodos e ferramentas de engenharia de software, avaliar retorno de investimento, identificar as melhores práticas de desenvolvimento de software, embasar solicitações de novas ferramentas e treinamento, avaliar o impacto da variação de um ou mais atributos do produto ou do processo na qualidade e/ou produtividade, formar uma baseline para estimativas, melhorar a exatidão das estimativas, oferecer dados qualitativos e quantitativos ao gerenciamento de desenvolvimento de software, de forma a realizar melhorias em todo o processo de desenvolvimento de software etc. (ZANCHETT, 2015). Existem vários métodos que podem ser utilizados para se estimar o custo do desenvolvimento e a vida útil de um sistema. Em geral, representa o custo monetário ou o esforço necessário para desenvolver e manter um sistema. Para se estabelecer essas estimativas, podem-se utilizar técnicas de decomposição do produto e utilizar a opinião de especialistas que, baseados em experiências de projetos anteriores, são capazes de estimar o esforço e o tempo de desenvolvimento do projeto. Podem-se considerar dois tipos de decomposição: (1) decomposição do produto para estimar o número de linhas de código utilizando técnicas como pontos por função, caso de uso etc.; (2) decomposição do processo considerando-se as atividades de cada etapa de engenharia de software, dependendo do paradigma utilizado. A seguir são apresentados métodos ou técnicas para estimativa de software, que são: Linhas de Código (LOC); Pontos de História; Análise de Pontos de Função, Análise de Pontos de Caso de Uso, COCOMO II e estimativa para projetos Orientados a Objeto. • Linha de Código (LOC): é métrica orientada ao tamanho do software, consiste em estimar o número de linhas que um programa deverá ter. Para sua definição são considerados três valores, o LOC otimista, o LOC pessimista e o LOC esperado, e a partir dos dados coletados seus valores são aplicados na fórmula: KSLOC = 4*KSLOC esperado + KSLOC otimista + KSLOC pessimista)/6.

Análise e desenvolvimento de sistemas em Foco

9

10

• Pontos de História: é uma métrica de estimativa de tempo, pergunta-se à equipe quanto tempo tantas pessoas que se dedicassem a uma história de usuário levariam para terminá-la, gerando uma versão executável funcional. Então, multiplica-se o número de pessoas pelo número de dias para chegar ao valor de pontos de história. • Análise de Pontos de Função (APF): define processos e técnicas formais e padronizadas para dimensionamento e estimativa da complexidade de sistema, ou seja, para medir o tamanho do escopo. Para manter e determinar os procedimentos de contagem APF observa-se os seguintes passos: (1) Determinar o tipo de contagem (desenvolvimento, melhoria ou aplicação existente). (2) Determinar as Fronteiras da aplicação (escopo do sistema). (3) Identificar e atribuir valor em pontos de função não ajustados para as transações sobre dados (entrada, consultas e saídas externas). (4) Identificar e atribuir valor em pontos de função não ajustados (UFPA) para os dados estáticos (arquivos internos e externos). (5) Determinar o valor de ajuste técnico (VAF). (6) Calcular o número de pontos de função ajustados (AFP). • Pontos de Caso de Uso (PUC): baseia-se na análise da qualidade e complexidade dos atores e casos de uso, o que gera pontos de caso de uso não ajustados. Depois, a aplicação e fatores técnicos e ambientais levam aos pontos de caso de uso ajustados. Primeiro deve-se relacionar os atores, classificálos de acordo com seu nível de complexidade (simples, médio ou complexo), atribuindo respectivamente os pesos 1, 2 ou 3. Em seguida, contar os casos de uso e atribuir o grau de complexidade, sendo baseada no número de classe e transações. Utiliza-se a seguinte fórmula para calcular PCUs não ajustados: PCUNA = TPNAA+ TPNAUC, e para chegar ao PUCs ajustado determina-se o fator de complexidade técnica, que varia da escala de 0 a 5 para cada grau de dificuldade do sistema a ser construído e, por fim, chega-se ao valor PUCs ajustado utilizando a seguinte fórmula: PCUA = PCUNA * Fator de complexidade técnica * Fator de complexidade ambiental. E para 8. Calcular a estimativa de horas de programação, basta multiplicar o PCUs ajustado pelo número pessoa hora por unidade de PCU (ZANCHETT, 2015). • Modelo COCOMO II: é um modelo construtivo de custo que trata das seguintes áreas: Modelo de composição de aplicação, Modelo de estágio de início do projeto e Modelo de estágio pós-arquitetura.

Análise e desenvolvimento de sistemas em Foco

Para requerer informações de tamanho como parte da hierarquia do projeto há disponíveis três diferentes opções: pontos de objeto, pontos de função e linhas de código-fonte. • A contagem de pontos de objeto é então determinada multiplicando-se o número original de instâncias de objeto pelo fator de peso e somando para obter o total da contagem de pontos de objeto. Quando deve ser aplicado desenvolvimento baseado em componentes ou reutilização de software em geral, é estimada a porcentagem de reutilização (% reúso) e é ajustada a contagem de pontos de objeto: NOP = (pontos de objeto) * [(100 - % reúso)/100]. Em que NOP é definido como novos pontos de objeto. • Para derivar uma estimativa de esforço com base no valor calculado para NOP, deve ser derivada uma “taxa de produtividade”. O quadro abaixo apresenta a taxa de produtividade: PROD = (NOP)/pessoa-mês. Para diferentes níveis de experiência do desenvolvedor e maturidade do ambiente de desenvolvimento. Uma vez determinada a taxa de produtividade, calcula-se a estimativa de esforço do projeto: Esforço estimado = NOP/PROD. 11

QUADRO 1 – FATORES DE AJUSTES

FONTE: Pressman (2011)

• Estimativa para projetos Orientados a Objeto: utilize qualquer método anterior para decomposição de esforço, valendo-se da modelagem UML através da PCU, determine o número de classes-chave e classifique o tipo de interface para a aplicação, desenvolva um multiplicador para classes e multiplique o número das classes-chave pelo multiplicador para obter uma estimativa do número de classes de apoio. Multiplique o número total das classes (classes-chave + classe de apoio) pelo número médio de unidades de trabalho por classe.

Análise e desenvolvimento de sistemas em Foco

8 QUALIDADE DE SOFTWARE Em desenvolvimento de software, a qualidade deve ser entendida nos aspectos da correta compreensão dos requisitos do cliente, quando se desenvolve o projeto com zero defeito, quando se obtém aumento de produtividade e redução de custos e, por fim, uma boa usabilidade do sistema. A qualidade está fortemente relacionada à conformidade com os requisitos, ou seja, atender ao que o usuário pede formalmente. Na área de Engenharia de Software, segundo Roger Pressman (2011) a qualidade é definida como sendo a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido.

12

A Organização Internacional de Padronização (International Organization for Standardization - ISO), através da ISO 9000, define qualidade como a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. As necessidades implícitas são necessidades subjetivas dos usuários, também chamadas de fatores externos, e podem ser percebidas tanto pelos desenvolvedores quanto pelos usuários (ISO, 2015). Qualidade de software está relacionada a entregar ao cliente o produto final que satisfaça suas expectativas, dentro daquilo que foi acordado inicialmente por meio dos requisitos do projeto. Nesse contexto, qualidade de software que objetiva garantir essa qualidade pela definição de processos de desenvolvimento (ENGHOLM JR., 2010). Para produzir um produto de software com qualidade deve-se possuir processos formais que visem à prevenção e detecção de defeitos durante o desenvolvimento de software. A origem do produto se dá pela implementação de um processo consistente e em constante melhoria contínua.

Análise e desenvolvimento de sistemas em Foco

FIGURA 2 – DESENVOLVIMENTO DE PRODUTO DE SOFTWARE

FONTE: O autor

Várias técnicas são utilizadas para identificar defeitos nos produtos de trabalho. Esses defeitos são eliminados através de retrabalho, que tem efeito imediato na produtividade do projeto. Defeitos também são encontrados em atividades de teste e podem ser analisados, a fim de se identificar suas causas. A partir dessa análise, lições aprendidas podem ser usadas para criar futuros produtos e prevenir futuros defeitos e, dessa forma, ter impacto positivo na qualidade do produto e na produtividade do projeto. Todo processo de software deve possuir, junto ao plano de projeto, uma documentação específica da qualidade, denominada como plano de qualidade, que deve compreender informações sobre como a equipe de qualidade irá garantir o cumprimento da política de qualidade, no contexto do programa ou projeto a ser desenvolvido, quais métodos, técnicas, métricas, treinamentos e padrões devam ser utilizados ao longo de todo o ciclo de vida do projeto. O plano deve oferecer a base do gerenciamento dos riscos, dos testes, das inspeções, das auditorias e como deverão ocorrer os reportes de problemas e ações corretivas. FONTE: Disponível em: . Acesso em: 8 maio 2016.

Análise e desenvolvimento de sistemas em Foco

13

Pode-se citar, entre tantos outros exemplos, que a técnica de prevenção de defeitos em um processo de desenvolvimento de software se dá pelo uso de instruções de procedimentos (padrões formais), treinamentos, documentação, modelagem e reengenharia; já as técnicas de detecção de defeitos podem ser pela análise de código; revisão por pares; testes, auditorias, verificações e validações. Na gestão da qualidade de software existem diversas atividades voltadas à garantia da qualidade e ao controle de qualidade de software. A primeira é para a definição padronizada das atividades voltadas à prevenção de defeitos e problemas, que podem surgir nos produtos de trabalho. Área que define padrões, metodologias, técnicas e ferramentas de apoio ao desenvolvimento tendo como entrada o plano de qualidade de software e os resultados de medições de qualidade. A segunda é voltada para o monitoramento de resultados específicos do projeto, ou seja, a detecção de defeitos, executada através do uso de técnicas que incluem revisões por pares, teste e análise de tendências, entre outras. Observe o quadro com as principais diferenças entre elas (VASCONCELOS et al., 2006).

14

Análise e desenvolvimento de sistemas em Foco

QUADRO 2 – GARANTIA DE QUALIDADE X CONTROLE DE QUALIDADE

Garantia da Qualidade 1. Garantia da qualidade garante que o processo é definido e apropriado. 2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. 3. Garantia da qualidade é orientada ao processo. 4. Garantia da qualidade é orientada à prevenção. 5. Foco em monitoração e melhoria de processo. 6. As atividades são focadas no início das fases no ciclo de vida de desenvolvimento de software. 7. Garantia da qualidade garante que você está fazendo certo as coisas e da maneira correta.

Controle da Qualidade 1. As atividades de controle da qualidade focam na descoberta de defeitos específicos. 2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?". 3. Controle da qualidade é orientado a produto. 4. Controle da qualidade é orientado à detecção. 5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados. 6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. 7. Controle da qualidade garante que os resultados do seu trabalho são os esperados, conforme requisitos.

FONTE: Disponível em: . Acesso em: 20 set. 2015.

Roger Pressmann (2011) definiu que a Engenharia de Software é composta em uma tecnologia em camadas com Foco em Qualidade, em que se dá ênfase à preocupação da disciplina, padronização e satisfação do cliente. Foco em Processo, em que se dá ênfase no planejamento das atividades e no controle do projeto de software. Foco em Métodos, em que se dá ênfase às abordagens e às atividades necessárias para a construção de um software. Foco em Ferramentas, em que se dá ênfase ao apoio automatizado ou semiautomatizado para processos e métodos.

Análise e desenvolvimento de sistemas em Foco

15

A engenharia de software pode ser considerada uma tecnologia, com métodos e ferramentas próprios, estruturada em camadas, do ponto de vista sistêmico. A abordagem sistêmica da engenharia de software deve se apoiar num compromisso organizacional com a qualidade que leve à cultura de um processo contínuo de aperfeiçoamento, e é essa cultura que, em última análise, leva ao desenvolvimento de abordagens cada vez mais efetivas. A camada de base em que a engenharia de software se apoia é o foco na qualidade, e o “adesivo” que mantém unidas as camadas, estruturadas segundo a visão sistêmica, é o processo (ZANCHETT, 2015). As dimensões da qualidade de software: Qualidade do processo, qualidade das pessoas, tecnologia de desenvolvimento, custo, tempo e cronograma.

9 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE 16

Entre os principais objetivos da qualidade de software está a definição de técnicas e ferramentas para serem utilizadas durante o ciclo de vida do projeto, PADRONIZANDO a forma de realizar as atividades, um guia de trabalho proporcionando assertividade no projeto, evitando erros humanos. Diversos padrões e normas de qualidade de software vêm sendo propostos ao longo dos anos. Essas normas têm sido fortemente adotadas nos processos de software das organizações em todo o mundo. As normas da International Organization for Standardization (ISO, 2015) são padrões internacionais que “especificam requisitos para um sistema gerencial de qualidade de uma organização”. Com o crescimento substancial das indústrias de software e levando-se em conta que a produção de software apresenta características peculiares, a ISO tem trabalhado na definição de várias normas que podem ser utilizadas como guias e padrões para diversas áreas de atuação dentro do contexto da ciência da computação. As principais normas ISO aplicadas à qualidade de produto ou processo de software são:

Análise e desenvolvimento de sistemas em Foco

• Norma ISO/IEC 9000: é um conjunto de documentos que engloba pontos referentes à garantia da qualidade em projeto, desenvolvimento, produção, instalação e serviços associados; objetivando a satisfação do cliente pela prevenção de não conformidades em todos os estágios envolvidos no ciclo da qualidade da empresa. • Norma ISO/IEC 12207: é o estabelecimento de uma estrutura comum utilizada como referência para os processos de ciclo de vida de software considerando que o desenvolvimento e a manutenção de software devem ser conduzidos da mesma forma que a disciplina de engenharia. • Norma ISO/IEC 15504: possui um conjunto de nove documentos que endereçam avaliação de processo, assessoria de treinamento e competência, determinação da capacidade e melhoria de processo e está se tornando um modelo de referência para outros padrões, como o CMMI. • Norma ISO/IEC 9126: estabelece um modelo de qualidade para o produto de software que é avaliado conforme seis categorias básicas, que são subdivididas em algumas características que são importantes para cada categoria: funcionalidade, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade. • Norma ISO/IEC 27000: trata sobre a área de segurança da informação através de Requisitos do SGSI; Controles de Segurança; Diretrizes de Implementação; Medição; Gestão de Risco e Auditoria de Segurança. • Norma ISO/IEC 15939: define um processo de medição aplicável a sistemas, engenharia de software e disciplinas de gestão. Os modelos de qualidade mais difundidos nas indústrias de software no Brasil são o CMMI e MPS.BR. O principal propósito do CMMI (Capability Maturity Model Integration ou Integração dos Modelos de Capacitação e Maturidade de Sistemas) é fornecer diretrizes baseadas em melhores práticas para a melhoria dos processos e habilidades organizacionais, cobrindo o ciclo de vida de produtos e serviços completos, nas fases de concepção, desenvolvimento, aquisição, entrega e manutenção. O CMMI é um dos modelos mais aceitos para a melhoria da qualidade e do processo de software em todo o mundo e define os princípios e práticas que devem ser aplicados a uma organização para atingir estágios evolutivos de maturidade em seu processo de software. Os cinco níveis de maturidade são: (1)

Análise e desenvolvimento de sistemas em Foco

17

Inicial: processo imprevisível e sem controle. (2) Repetível: processo disciplinado. (3) Definido: processo consistente e padronizado. (4) Gerenciado: processo previsível e controlado e (5) Otimização: processo aperfeiçoado continuamente. O MPS. BR (Melhoria de Processo de Software Brasileiro) é um programa que foi criado para melhorar a capacidade de desenvolvimento de software nas empresas brasileiras voltados para médias e pequenas empresas e com baixo custo de implantação. MPS.BR possui as seguintes metas: (1) definir e implementar o Modelo de Referência para Melhoria de Processos de Software (MR mps); (2) criar cursos em diversos locais do país para capacitar e formar consultores do modelo; (3) credenciar instituições e centros tecnológicos capacitados a implementar e avaliar o modelo com foco em grupo de empresas.

18

Os sete níveis de maturidade do MPS.Br são: (G) Parcialmente gerenciado: inicia o gerenciamento de requisitos e projetos; (F) Gerenciado: inclui medições, gerência de configurações e garantia de qualidade; (E) Parcialmente definido: inclui treinamento, adaptação de processos para gerência de projetos; (D) Largamente definido: envolve teses e integração de produto; (C) Definido: gerência de riscos; (B) Gerenciado quantitativamente: avalia o desempenho dos processos e a gerência quantitativa dos mesmos; e (A) em otimização: preocupação com a inovação e análise de causas (ZANCHETT, 2015). Segundo Franciscani e Pestili (2015), existem medições entre os modelos, e as comparações entre eles podem ser visualizadas no quadro a seguir. QUADRO 3 – COMPARATIVO ENTRE OS MODELOS CMMI E MPS.BR

CMMI

MPS.BR

O modelo de Qualidade CMMI é O MPS.BR é mais conhecido reconhecido internacionalmente. nacionalmente e na América Latina. O modelo CMMI envolve um grande No MPS.BR o custo da certificação é custo na avaliação e certificação do mais acessível. modelo.

Análise e desenvolvimento de sistemas em Foco

No CMMI é necessário investir tempo, geralmente para se chegar aos níveis No MPS.BR as avaliações são bienais. de maturidade mais altos. O CMMI tem foco global voltado para MPS.BR é um modelo criado em função empresas de maior porte. das médias e pequenas empresas. O CMMI possui cinco níveis de MPS.BR possui sete níveis de maturidade por estágio e seis na maturidade, onde a implementação é contínua. mais gradual. O CMMI é aceito como maturidade O MPS.BR é o aceito como maturidade para licitações. para licitações. O CMMI torna as empresas O MPS.BR não torna as empresas competitivas internacionalmente. competitivas internacionalmente. No MPS.BR pode acontecer contrato O CMMI não utiliza contrato conjunto cooperado em grupo de empresas que de empresas. queiram a certificação. Implementação mais complexa. Desenvolvido

pelo

Implementação mais simples.

Software Desenvolvido por algumas instituições

Engineering Institute – SEI em 1992.

brasileiras em 2003.

FONTE: Franciscani e Pestili (2015)

10 MÉTODOS ÁGEIS As Metodologias Ágeis de Desenvolvimento de Software são indicadas como sendo uma opção às abordagens tradicionais para desenvolver softwares: produzem pouca documentação, é recomendado documentar somente o que será útil. Em essência, as Metodologias Ágeis foram desenvolvidas com o objetivo de vencer as fraquezas percebidas e reais da Engenharia de Software (PRESSMAN, 2010). Segundo Souza (2015), os 12 princípios do Manifesto Ágil são: 1. Garantia da satisfação do consumidor com entrega rápida e contínua de softwares funcionais. 2. Mudanças de requisitos, mesmo no fim do desenvolvimento, ainda são bemvindas.

Análise e desenvolvimento de sistemas em Foco

19

20

3. Frequentemente são entregues softwares funcionais (semanas, ao invés de meses). 4. Desenvolvedores e pessoas relacionadas aos negócios devem trabalhar, em conjunto, até o fim do projeto. 5. Construir projetos com indivíduos motivados, dar-lhes ambiente e suporte necessários e confiar que farão seu trabalho. 6. Uma conversa face a face é o método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe de desenvolvimento. 7. Software em funcionamento é a principal medida de progresso. 8. Desenvolvimento sustentável, de modo a manter um ritmo constante indefinidamente. 9. Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade. 10. Simplicidade – a arte de maximizar a quantidade de trabalho não efetuado – é essencial. 11. As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizáveis. 12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficiente. Entre todos os métodos ágeis podem-se citar como exemplo o Scrum e o Extreme Programming.

10.1 SCRUM Scrum é um método ágil de desenvolvimento de software criado por Jeff Sutherland e sua equipe no início de 1990. O Scrum considera uma abordagem mais humana ao solucionar os problemas existentes no desenvolvimento de software. Ao invés de desperdiçar tempo criando documentações extensas e detalhadas que as pessoas acabam não lendo minuciosamente, no Scrum as equipes trabalham com Sprints. São realizadas reuniões curtas onde o time verifica quais as decisões que devem ser tomadas e os recursos do product backlog que entram nos sprints. Elas também decidem quem trabalha nos sprints e quanto tempo dura cada tarefa (DIMES, 2014).

Análise e desenvolvimento de sistemas em Foco

O Scrum serve como fundamento para um projeto complexo, não ditando regras que devem ser estritamente seguidas, mas que podem ser personalizadas conforme a necessidade da equipe, servindo como base para uma gerência de sucesso. O Scrum é um método orientado a iterações, sendo elas chamadas de Sprints. As entradas de sprints ocorrem normalmente uma vez por mês. Os requisitos e funcionalidades a serem desenvolvidas em um determinado projeto são armazenados em uma lista conhecida como Product Backlog. Ao iniciar-se um Sprint, é realizada uma reunião de planejamento, na qual o Product Owner dita quais as principais funcionalidades a serem implementadas e à equipe as atividades que será capaz de produzir. As funcionalidades que serão implementadas em um Sprint são removidas do Product Backlog e alocadas no Sprint Backlog. A cada dia é realizada uma reunião, analisando o que foi produzido no dia anterior e o que será produzido no dia atual. Essa reunião é chamada de Daily Scrum e acontece normalmente no início da manhã. Ao fim de um Sprint, a equipe apresenta os requisitos e funcionalidades desenvolvidas em uma Sprint Review Meeting. Após uma retrospectiva, a equipe de desenvolvimento passa para o planejamento do próximo Sprint. A divisão de tarefas no Scrum baseia-se em Sprints e Reuniões Diárias. O Sprint é o ciclo em que diversas atividades precisam ser feitas e entregues no final para que possam ser entregues para o cliente, possuem duração fixa, normalmente de duas a quatro semanas, mas podem ser adaptadas de acordo com a necessidade da empresa, desde que mantenha a entrega constante. Para ajudar a manter o time atualizado, é comum no Scrum que todos os dias, no mesmo horário, seja realizada uma breve reunião em pé, que consiste em três pequenas perguntas: “O que fiz ontem em relação ao projeto?”, “O que vou fazer hoje em relação ao projeto?”, “Existe algum impedimento para que a meta do Sprint seja alcançada?”. Ao responder estas perguntas, o time saberá como está indo o andamento do projeto.

Análise e desenvolvimento de sistemas em Foco

21

10.2 EXTREME PROGRAMMING A metodologia de desenvolvimento Extreme Programming (XP) é uma metodologia baseada em comportamentos e atitudes, tem foco em agilidade de equipes e qualidade de projetos. Sommerville (2011) afirma que nesse método a diferença está na forma como o sistema é testado. Não existe especificação do sistema que possa ser usada por uma equipe de teste externa. Para evitar problemas nos testes, a abordagem XP enfatiza a importância dos testes do programa, incluindo um foco de testes que reduz as chances de erros não identificados na versão atual do sistema. A Programação Extrema valoriza o trabalho em equipe, desenvolvedores, administradores e clientes são todos iguais e todos precisam estar dispostos a ajudar quando necessário. Portanto, sua principal característica é a PROGRAMAÇÃO EM PARES.

22

Baseia-se em cinco princípios fundamentais: comunicação, simplicidade, feedback, respeito e coragem e em diversas regras simples, além das já definidas pelo desenvolvimento ágil: o código deve ser escrito usando a técnica de programação em par, todo código deve ter testes unitários, o tempo deve ter um bom espaço para trabalhar, um novo teste será criado quando um bug for encontrado, entre outras regras específicas. Conforme destacado por Souza (2015), o Extreme Programming utiliza a Orientação ao Objeto como paradigma de desenvolvimento, onde inclui um conjunto de regras e práticas com base nas seguintes atividades: Planejamento, Projeto, Codificação e Teste. No planejamento é realizada a criação de um conjunto de “histórias de usuários” descrevendo as características e funcionalidades requeridas pelo software que será construído, estas histórias (semelhantes aos casos de uso) são escritas pelos clientes e colocadas em cartões de indexação, então o cliente atribui uma prioridade a cada história e os desenvolvedores analisam cada história e atribuem um custo a cada uma delas, com base em número de semanas necessárias para o seu desenvolvimento. Se a história precisar de mais de três semanas para desenvolvimento, é solicitado ao cliente que ela seja dividida em histórias menores e, por fim, com o avanço do projeto, o cliente pode adicionar novas histórias, mudar a sua prioridade, subdividi-las e eliminá-las.

Análise e desenvolvimento de sistemas em Foco

11 TESTES DE SOFTWARE Sommerville (2011) destaca que o teste de software serve para evidenciar que o programa faz o que ele realmente deve fazer e para evidenciar os defeitos que existem antes do uso. No processo de teste existem dois objetivos distintos, que são: demonstrar que o software atende seus requisitos e descobrir em que situação o software se comporta de forma incorreta. O teste busca descobrir a maior quantidade de defeitos possível, é importante saber onde os defeitos podem estar. Saber como os defeitos são criados nos dá pistas sobre onde procurá-los durante o teste do sistema (PFLEEGER, 2004). A tarefa de efetuar testes, em software, foi considerada secundária por muito tempo. Geralmente, era vista como castigo para o programador ou como uma tarefa, onde não se deveria gastar muito tempo e investimentos. O tema esteve relegado a segundo plano e, até alguns anos atrás, não se encontrava muita literatura sobre o assunto. Este é um paradigma que vem mudando no mundo moderno de desenvolvimento de software. Um dos testes, que ajudou a mudar este paradigma, é o teste de aceitação, que tem como principal característica verificar o sistema, em relação aos seus requisitos originais e às necessidades atuais do usuário. O teste de software constitui-se em uma etapa importante no ciclo de desenvolvimento de software. Uma das características mais importantes de um conjunto de testes de software, adequadamente planejados, é ter alta probabilidade de detectar erros no programa sob teste (ZANCHETT, 2015). Os testes de software são executados usando os procedimentos e documentos de script de teste. Para que a fase de execução de teste seja realizada com sucesso deve(m) ser executado(s) os casos de teste. A validação é verificar se o software tem todos os itens necessários para atender ao cliente. O sistema que será entregue ao cliente vai ajudá-lo e o mesmo vai ficar contente. Para a validação a pergunta é: "Fizemos o software correto?" A verificação fica escondida do usuário final, em comparação à validação. Os encarregados devem buscar e prever erros entre os requisitos. Verificar se todas

Análise e desenvolvimento de sistemas em Foco

23

as etapas de desenvolvimento conforme planejado foram realizadas e da melhor forma. Para a verificação a pergunta é: "Fizemos o software corretamente?". Realizar os testes nada mais é que entrar com vários dados de maneira diferente e analisar os dados de saída e seu comportamento. Aqui são realizados vários tipos de teste, como, por exemplo, teste de interface, de regras de negócio e de carga. Para testar a pergunta é: "O software tem defeito?". Teste de software é o processo que visa sua execução de forma controlada, com o objetivo de avaliar o seu comportamento baseado no que foi especificado. A execução dos testes é considerada um tipo de validação. Na área de testes, os tipos de Teste Caixa Preta, que visam verificar a funcionalidade e a aderência aos requisitos, em uma ótica externa ou do usuário, sem se basear em qualquer conhecimento do código e da lógica interna do componente testado, e os de Teste Caixa, que visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos. 24

Os tipos de testes conforme seus níveis são: • Teste de Unidade: o teste é realizado em cada componente do programa isoladamente, no qual se verifica se ele funciona de forma adequada aos tipos de entradas esperadas. • Teste de Integração: tem o objetivo de provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. • Teste de Sistema: avalia o software em busca de falhas utilizando o mesmo como se fosse um usuário final. • Teste de Aceitação: é realizado em conjunto com os clientes e nele o sistema é verificado em comparação com a descrição dos requisitos do cliente. Segundo Zanchett (2015), as práticas de desenvolvimento na área de testes são: • TDD – Test - Driven Development: o Desenvolvimento Guiado a Testes; se escreve primeiramente os testes para posteriormente escrever o código, o

Análise e desenvolvimento de sistemas em Foco

•

•

•

•

processo aborda os parâmetros Red, Green e Refactor: (1) Escrever um teste, mesmo sem ter escrito o código real a ser testado; (2) Executar os testes e acompanhar a falha (Red); (3) Escrever a funcionalidade do sistema que irá ser testada; (4) Testar novamente, agora para passar (Green); (5) Refatorar a funcionalidade e escrever por completo (Refactor); (6) Próxima estória ou caso de uso e iniciar novo teste. DDD – Domain - Driven Design: no desenvolvimento guiado ao domínio o foco é no Domínio do Software, no propósito que o software deve atender, é a automatização de um processo de negócio. O DDD traz abordagens de como fazer isto, como atender um domínio complexo de informações. Qualquer abordagem de DDD é muito bem aceita numa metodologia ágil. BDD – Behavior - Driven Development: o desenvolvimento guiado por comportamento, associa os benefícios de uma documentação formal, escrita e mantida pelo negócio, com testes de unidade que demonstram que essa documentação é efetivamente válida. Na prática, isso garante que a documentação deixa de ser um registro estático, que se converte em algo gradualmente ultrapassado, em um artefato vivo que reflete constantemente o estado atual de um projeto. ATDD - Acceptance Test - Driven Development: o desenvolvimento guiado por testes de aceitação; o trabalho ocorre em resposta a testes de aceitação. O ATDD pode ser considerado como análogo ao TDD. FDD - Feature Driven Development: desenvolvimento guiado por funcionalidades, serve para gerenciar e desenvolver projetos de software através de um conjunto de atividades simplificadas, de maneira a estimular o compartilhamento do conhecimento acerca do software e da criação de bons códigos.

Análise e desenvolvimento de sistemas em Foco

25

Análise e desenvolvimento de sistemas em Foco

------------ [ TÓPICO 2 - PROGRAMAÇÃO ORIENTADA A OBJETOS ] -----------Caro(a) acadêmico(a), vamos dar início ao estudo do tema Programação Orientada a Objetos, assunto de extrema importância no cenário atual. Abordaremos os seguintes assuntos: Conceitos da Programação Orientada a Objetos, Projeto Orientado a Objetos, Objetivos da Modelagem, Vantagens do Projeto OO, Diagramas Estruturais, Diagramas Comportamentais, Padrão de Projetos, Vantagens do uso de padrões e quais são os padrões mais utilizados. Iniciaremos os estudos empregando o máximo de atenção e foco para que os resultados sejam os melhores possíveis. Vale ressaltar que os assuntos aqui abordados estão listados de forma resumida, e em caso de dúvidas, o caderno da disciplina deve ser consultado. Esperamos que esse resumo contribua para o incremento e fixação dos seus conhecimentos! Profª. Simone Cristina Aléssio 27 1 CONCEITOS DA PROGRAMAÇÃO ORIENTADA A OBJETOS Orientação a objetos é uma tecnologia que visualiza os sistemas como um conjunto de objetos. Foi desenvolvida pensando na reutilização de componentes, utilizando-se de conceitos como abstração, hierarquização, modularização, relacionamento e persistência. Um modelo orientado a objetos é composto por quatro elementos básicos: Objeto: é um conjunto de métodos que gravam e recuperam dados de operações. Um objeto possui todas as informações de si mesmo. Executa operações de acordo com mensagens recebidas. Um objeto pode enviar mensagens para outros objetos e o resultado da operação depende diretamente do estado do objeto quando o mesmo recebe a mensagem. Mensagem: são solicitações/requisições enviadas ao objeto receptor com o intuito de obter um resultado. Métodos: procedimento executado pelo objeto na busca por um resultado, quando recebe uma mensagem.

Análise e desenvolvimento de sistemas em Foco

28

Atributos: definem as características do objeto. Classe: pode ser entendida como um conjunto de atributos que definem as características de um objeto. Encapsulamento: visão do objeto no estado interno, incluindo suas mensagens e métodos. Polimorfismo: permite que a mesma mensagem seja enviada por mais de um objeto. Herança: é uma característica importantíssima, pois permite que as subclasses herdem componentes da classe pai. Permite a criação de novas classes sem ocasionar redundância de código. A Programação Orientada a Objetos surgiu como uma evolução da programação procedural e da programação modular. A possibilidade de reutilizar componentes é a sua principal contribuição. Isso é possível através das propriedades herança e polimorfismo. O alicerce da orientação a objetos são os objetos e a troca de mensagens que ocorre entre os mesmos. A instanciação pode ser entendida como a criação de um objeto tendo como origem uma classe. As classes têm nome, atributos e métodos. A linguagem de programação Java é uma das linguagens mais utilizadas no desenvolvimento orientado a objetos. É multiplataforma, pois sua compilação é executada por uma máquina virtual, que separa detalhes do sistema operacional.

• • • •

A plataforma Java se divide basicamente em quatro grandes grupos: JavaSE – utilizado para desenvolvimento de aplicações desktop. JavaEE – utilizado para aplicações em ambientes distribuídos, multitarefa e complexos. JavaME – usado para dispositivos menores, como cartões, telefones, microchips etc. JavaFX – permite a criação de RIA em Java. Pertence à Oracle.

Aplicações Java disponibilizam alguns recursos particulares que garantem a sua otimização. Logo, tende a ser mais rápida que o desenvolvimento em C e C++, em determinadas situações. Os atributos representam as informações de uma classe. Exemplo: Classe CARRO – atributos: marca, cor, modelo. Cada atributo deve ser tipado, pois a linguagem

Análise e desenvolvimento de sistemas em Foco

usa amplamente o conceito de tipagem. A tipagem consiste em atribuir um tipo de dado para o atributo (se ele é do tipo texto ou numérico, por exemplo). Nesta linguagem o nome dos atributos começa com letra maiúscula. Se um atributo tiver dois nomes, o primeiro começa com letra maiúscula e os demais ficam todos em minúsculo. Os métodos são as operações invocadas pelos objetos, cujo retorno pode ser 0 ou 1 como retorno. O retorno pode ser de qualquer tipo, inclusive classes. Caso não retorne nada, utiliza-se a palavra void. Métodos começam com um verbo no infinitivo seguido de um substantivo. Exemplo: calcularSalario(). Parâmetros podem ser passados aos métodos para que executem suas operações, usando-os como filtros. Estes podem ser de qualquer tipo de dados, ou podem ser classes. Porém, determina-se um número máximo de cinco parâmetros por método segundo as boas práticas da linguagem JAVA. Instanciar uma classe significa que ela é um objeto em memória que já pode ser usado no programa. Somente neste momento os valores são associados aos atributos, e os métodos estão liberados para serem invocados. Do contrário, o compilador coloca o programa na sessão de exceções. Os valores dos atributos representam o estado deste objeto, e os métodos, o seu comportamento. A herança permite o relacionamento entre classes, onde uma superclasse fornece o estado e comportamento que serão herdados por outras classes. As classes inferiores no relacionamento são conhecidas subclasses. Uma classe mãe tem várias filhas. Mas uma classe filha pode estar associada somente a uma classe mãe. Hierarquias de herança devem ter no máximo dois ou três níveis, sendo que não existe herança múltipla em JAVA. É possível passar atributos ou métodos para classes filhas utilizando-se o modificador protected, mas ambos ficam privados para outros pacotes. Uma desvantagem da herança é que ela quebra o encapsulamento. Uma alternativa é o uso da composição, onde uma classe possui um atributo do tipo classe e que pode ser reutilizado. A composição permite a reutilização de códigos e componentes de outras classes sem violar o encapsulamento.

Análise e desenvolvimento de sistemas em Foco

29

2 PROJETO ORIENTADO A OBJETOS Projeto orientado a objetos é apenas uma das etapas do processo de desenvolvimento de software orientado a objetos. • No projeto orientado a objetos os desenvolvedores pensam nas coisas, nos • • • • •

30

objetos, em vez de se focar nas suas funcionalidades. É uma arquitetura voltada para os serviços ofertados pelos objetos. Objetos representam algo do mundo real e são autogerenciáveis. Objetos são independentes entre si e encapsulam representações de informação e estado. As áreas de dados compartilhados entre os objetos são eliminadas. A troca de mensagens faz a comunicação entre os objetos.

O projeto orientado a objetos divide-se em três etapas distintas: • Análise OO – propõe o desenvolvimento de um modelo O.O focado no domínio do aplicativo a ser desenvolvido. A identificação dos objetos relaciona-se com a realidade da situação-problema a ser resolvida. • Projeto OO – propõe a criação de um modelo O.O para implementar os requisitos do problema que deverá ser resolvido. • Programação OO – é a execução das etapas acima, implementada por uma linguagem de programação O.O. A modelagem é a base da tecnologia de orientação a objetos. Suas categorias principais são: • A dimensão estrutural dos objetos define a identidade de cada objeto, sua classificação, seu encapsulamento e seus relacionamentos. • A dimensão dinâmica do comportamento dos objetos é a representação dos estados válidos dos objetos e a especificação dos eventos que causam a transição desses estados. • A modelagem orientada a objetos é uma forma de pensar sobre problemas reais usando a UML para representá-los.

Análise e desenvolvimento de sistemas em Foco

3 OBJETIVOS DA MODELAGEM • Permitir uma visualização do sistema mais próxima da realidade. • Permitir especificar arquitetura e comportamento de todas as funcionalidades do sistema. • Fornecer padrões para desenvolver o sistema de forma organizada. • Documentar as decisões tomadas durante o processo de desenvolvimento. Após concluída a fase da análise orientada a objetos, dá-se início à fase do projeto propriamente dito, cujo planejamento e execução obedece algumas etapas, conforme os itens definidos abaixo: • • • • •

Compreender e definir o contexto e os modos de utilização do sistema. Projetar a arquitetura do sistema. Identificar os principais objetos do sistema. Descrever os modelos de projeto. Especificar as interfaces dos objetos. 31

4 VANTAGENS DO PROJETO OO • Facilidade de manutenção: torna mais rápida as atividades de programação e manutenção de sistemas de informação. • Os modelos gerados permitem maior compreensão. • A reutilização do código é mais eficiente. • A comunicação é mais segura e rápida. • Percebe-se uma maior estabilidade e flexibilidade nas construções. Modelos de objetos servem para especificar objetos e suas classes, e também, seus distintos relacionamentos. O modelo nada mais é do que o desenho do projeto em si. É o modelo que contém a informação entre o que é necessário no sistema, e como isso será alcançado. Por isso, os mesmos devem ser abstratos, não se importando com detalhes desnecessários ou secundários. O nível de detalhamento do projeto, aliás, deve

Análise e desenvolvimento de sistemas em Foco

ir até o ponto de favorecer o claro entendimento dos programadores, para que os mesmos decidam de forma assertiva pelas melhores formas de implementação. Dentre vários modelos, você terá que decidir qual será o mais viável e lhe permitirá o maior nível de detalhamento para o seu projeto. Para isso, você deverá ter em mente que tipo de projeto/sistema está construindo, pois, cada sistema tem suas necessidades específicas e pode apontar para modelos distintos. Poucos sistemas utilizam-se de todos os modelos. Reduzir o número de modelos implica em economia de tempo, recursos financeiros e humanos no desenvolvimento. Só para lembrar, existem dois tipos de modelos: estáticos e dinâmicos. Para a geração dos modelos utiliza-se atualmente a UML que se utiliza de diagramas na composição. A versão 2.0 da UML traz consigo 13 diagramas, divididos em quatro grupos:

32

• • • •

diagramas estruturais; diagramas comportamentais; diagramas de interação; diagramas de implementação.

5 DIAGRAMAS ESTRUTURAIS • De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes. • De Objeto: O Diagrama de Objeto está relacionado com o diagrama de classes e é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software. • De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos. • De Implantação: Determina as necessidades de hardware e características físicas do sistema.

Análise e desenvolvimento de sistemas em Foco

• De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem. • De Estrutura: Descreve a estrutura interna de um classificador.

6 DIAGRAMAS COMPORTAMENTAIS • De Caso de Uso (Use Case): Geral e informal para fases de levantamento e análise de Requisitos do Sistema. • De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo. • De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade. • De Interação: Dividem-se em: o De sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos. o Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio. o De comunicação: Associado ao diagrama de sequência, complementando-o e concentrando-se em como os objetos estão vinculados. o De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.

7 PADRÃO DE PROJETOS UML: Linguagem de modelagem unificada que permite padronizar a representação de um sistema. Não é uma metodologia de desenvolvimento. Presta auxílio para facilitar o entendimento da comunicação entre os objetos. Permite a visualização do sistema em diagramas padronizados, além de especificar, documentar e estruturar um sistema para uma pré-visualização.

Análise e desenvolvimento de sistemas em Foco

33

Padrões de projeto de software são utilizados para prover soluções reutilizáveis para problemas que ocorrem com frequência no processo de desenvolvimento de software. É necessário empenho e estudo para entender a correta aplicação dos padrões. O objetivo dos padrões é documentar e codificar conhecimentos para que estes possam ser aplicados em cenários distintos. Padrões ajudam na padronização e também na aprendizagem. É necessário que se tenha conhecimento sobre os limites e estrutura da solução, bem como os frameworks que servirão de suporte ao domínio. Frameworks são necessários para preencher os requisitos funcionais. Eles são elaborados após a definição da estrutura da solução. Os frameworks permitem compreender os objetos e suas relações no alicerce do problema. Essa compreensão é a primeira etapa na criação dos frameworks. Padrões impõem um vocabulário comum a todos os envolvidos no desenvolvimento de aplicativos computacionais. Todo padrão deve ter um nome, problema, solução, consequência e exemplo de utilização ou aplicação. 34

No desenvolvimento de software os padrões não são as classes, nem os objetos. Eles são utilizados para construir padrões de classes e objetos.

8 VANTAGENS DO USO DE PADRÕES • Facilitam a construção de softwares confiáveis através de arquitetura validada e testada. • Promovem a reutilização dos modelos em projetos futuros. • Ajudam a perceber erros comuns no desenvolvimento de sistemas. • Facilitam o desenvolvimento dos aplicativos independentemente da tecnologia utilizada. • Encurtam a fase do projeto no processo de desenvolvimento do software. Os padrões estão divididos em três categorias: estrutural, comportamental e de criação. É necessário observar os requisitos da solução, sua estrutura arquitetural e os modelos de análise para cada uma das categorias antes de iniciar a construção do framework.

Análise e desenvolvimento de sistemas em Foco

No total, a literatura apresenta hoje 23 padrões, conforme a Figura 1. FIGURA 1 – PADRÕES DE PROJETO

35

FONTE: Disponível em: . Acesso em: 23 maio 2015.

Os padrões atuais foram amplamente testados e validados. São bem definidos e documentados, facilitando a elaboração das soluções de diversos problemas quando são aplicados corretamente. Em 1979 surgiu a primeira versão do padrão MVC, que divide uma aplicação em três partes distintas e define a interação entre elas (controller, model, view). Ele separa a representação da informação da interação do usuário. • Um  controlador (controller): trata a entrada dos dados fazendo a conversão de comandos para o modelo e a visão.

Análise e desenvolvimento de sistemas em Foco

• Um  modelo (model): o modelo armazena os dados da aplicação. Representa a lógica e as regras do negócio. • A  visão (view): é a saída dos dados, que pode ser representada de qualquer forma, inclusive por tabelas. Os padrões são classificados em duas categorias distintas: finalidade e escopo. Os padrões são divididos em cinco grupos: Padrões de criação; Padrões estruturais; Padrões comportamentais; Padrões para classes; e Padrões para objetos. Nenhum padrão irá descrever um projeto novo ou que ainda não foi validado. A solução deve ser específica para o problema a ser resolvido, e genérica e abstrata o suficiente para ser replicada ou reutilizada na solução de problemas futuros e de tecnologias distintas. 36

Padrões devem ser considerados e usados como guias ou mapas, jamais como estratégia de solução. Padrões não devem ser considerados como um meio definitivo na solução. Padrões ajudam apenas a melhorar a implementação após a definição de todos os recursos necessários ao desenvolvimento do projeto. Antipadrão nada mais é do que fazer uso dos padrões de forma errada ou exagerada. Isso pode ser constatado pela utilização de padrões impróprios para um determinado contexto, ou uso inadequado em determinada situação. Para viabilizar um Projeto de Software Orientado a Objeto é primordialmente necessário definir como vai ocorrer a comunicação entre o usuário e o sistema, e as principais funcionalidades que o sistema disponibilizará para o mesmo.

Análise e desenvolvimento de sistemas em Foco

9 OS PADRÕES MAIS UTILIZADOS O Padrão Singleton: garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao objeto. O Padrão Factory Method: permite às classes delegar para subclasses decidirem. O factory method permite delegar a instanciação para as subclasses. O Padrão Abstract Factory: define uma interface para criar famílias de objetos sem especificar suas classes concretas. O Padrão Composite: utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. • O Padrão Decorator: permite adicionar um comportamento a um objeto já existente em tempo de execução. • O Padrão Façade: relaciona-se ao uso de bibliotecas; reduz as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema. • O Padrão Iterator: é um padrão para percorrer listas, conjuntos, mapas etc., como se fosse um cursor. • O Padrão Observer: permite que objetos interessados sejam avisados da mudança de estado. • O Padrão Template Method: monta o esqueleto de um algoritmo de uma forma abstrata, deixando que subclasses completem algumas das etapas. Novos padrões de projeto surgem a todo momento. Padrões para áreas específicas, como padrões de interface, padrões de persistência, padrões de arquitetura etc.

Análise e desenvolvimento de sistemas em Foco

37

Análise e desenvolvimento de sistemas em Foco

------- [ TÓPICO 3 - LÓGICA, ALGORITMOS E ESTRUTURA DE DADOS ] ------Caro(a) acadêmico(a), neste capítulo vamos relembrar alguns dos principais conceitos relacionados a uma das disciplinas essenciais ao nosso curso de Análise e Desenvolvimento de Sistema, a disciplina de Lógica, Algoritmos e Estrutura de Dados. Apresentaremos de forma condensada os temas que são os pilares desse assunto que introduz os alunos à lógica. Reforçamos que esse material visa oferecer ao acadêmico um conteúdo importante para sua vida acadêmica e profissional. Iniciaremos os estudos empregando o máximo de atenção e foco para que os resultados sejam os melhores possíveis, contribuindo para o incremento e fixação dos seus conhecimentos! Prof. Elton Giovani Gretter Profª. Greisse Moser Badalotti

39 1 LÓGICA DE PROGRAMAÇÃO Dentre as disciplinas essenciais para a formação do profissional da área de Análise e Desenvolvimento de Sistemas destaca-se a Lógica, a qual, segundo Bastos (1991), é a disciplina que trata das formas de pensamento, da linguagem descritiva do pensamento, das leis da argumentação e raciocínios corretos, dos métodos e dos princípios que regem o pensamento humano. De maneira geral, a palavra lógica encontra-se relacionada a uma forma distinta de raciocinar, a fim de justificar determinada situação, podendo ser classificada em Lógica Aristotélica, de Argumentação, Matemática, Proposicional e de Programação, sendo esta última a de maior relevância para os nossos estudos neste momento. A lógica de programação é essencial no desenvolvimento dos programas e sistemas informáticos (pois ela define o encadeamento lógico para esse desenvolvimento), os quais são denominados de algoritmos e consistem em uma sequência lógica de instruções para que a função seja executada.

Análise e desenvolvimento de sistemas em Foco

FIGURA 1 – EXEMPLO DE LÓGICA DE PROGRAMAÇÃO

FONTE: O autor

40

Segundo o Dicionário Aurélio (2010), algoritmo é: “Sequência de raciocínios ou operações que oferece a solução de certos problemas”. Nesse sentido, um algoritmo pode ser entendido como uma sequência de passos ou instruções, que têm por objetivo resolver determinado problema, desde situações mais rotineiras do cotidiano, como a receita para fazer um bolo, até situações mais complexas, como o desenvolvimento de um sistema computacional. Todavia, independentemente dos objetivos que se busca alcançar, para atingi-los há uma cadeia de passos que devem ser executados em uma sequência bem definida. Tomaremos por base que você, acadêmico, já detém os conhecimentos básicos sobre o desenvolvimento dos algoritmos e, portanto, abordaremos um conteúdo mais avançado, como: Estruturas de Seleção; Estruturas de Repetição; Funções Recursivas; Matrizes Multidimensionais; Listas Encadeadas; Pilhas, Filas e Pesquisa Binária.

1.1 ESTRUTURAS DE SELEÇÃO As estruturas de seleção permitem que um algoritmo tome caminhos distintos conforme determinada situação, e esses caminhos poderão executar as mais variadas instruções. Segundo Kochanski e Andrietti (2005, p. 49): “[...] a

Análise e desenvolvimento de sistemas em Foco

estrutura de seleção permite a definição de uma condição para que um conjunto de instruções seja ou não executado. Por esse motivo, as estruturas de seleção também são conhecidas como estruturas condicionais”.

1.1.1 “Se-então-senão” O comando SE-ENTÃO com base no resultado de uma condição, que pode retornar um valor Verdadeiro ou Falso, irá definir o fluxo do algoritmo, ou seja, estabelece qual bloco de instruções deve ou não ser executado. Este comando pode se apresentar de duas formas distintas, no entanto, sua função é a mesma: decidir por uma ou por outra alternativa. SE (condição) ENTÃO Instruções a serem executadas quando a condição for VERDADEIRA SENÃO Instruções a serem executadas quando a condição for FALSA> FIM-SE Importante ressaltar que o bloco de código SENÃO é opcional, sendo muito comum encontrarmos instruções de decisão apenas com SE-ENTÃO, sem o bloco SENÃO. Vejamos a utilização do comando em um caso prático.

Análise e desenvolvimento de sistemas em Foco

41

algoritmo CalculaMedia; var n1; n2; media : real; inicio escreva (“Informe a primeira nota: ”); leia (n1); escreva (“Informe a segunda nota: ”); leia (n2); media := (n1 + n2) / 2 SE (media >= 7) ENTÃO escreva (“O aluno está aprovado”) SENÃO escreva (“O aluno está reprovado”) FIM_SE fim.

42 1.1.2 Seleção Encadeada No exemplo visto no item anterior precisávamos verificar apenas duas situações: se o aluno havia sido Aprovado ou Reprovado com base na média obtida pelo mesmo. Todavia, existem casos em que haverá mais situações para serem analisadas, como, por exemplo, se o aluno está “Aprovado”, “em Exame” ou “Reprovado”, ocasião em que será necessária a utilização de uma Seleção Encadeada, ou seja, um comando SE-ENTÃO subordinado a outro comando SE-ENTÃO. Vamos estabelecer as regras e verificar como ficaria a estrutura deste algoritmo: Se a média for maior ou igual a 6.5, o aluno está aprovado. Se a média for maior ou igual a 5.0 e menor que 6.5, o aluno está em exame. Se a média for menor do que 5.0, o aluno está reprovado.

Análise e desenvolvimento de sistemas em Foco

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

algoritmo CalculaMedia; var n1; n2; media : real; inicio escreva (“Informe a primeira nota: ”); leia (n1); escreva (“Informe a segunda nota: ”); leia (n2); media := (n1 + n2) / 2 SE (media >= 6.5) ENTÃO escreva (“O aluno está aprovado”) SENÃO SE (media >= 5) ENTÃO escreva (“O aluno está em exame”) SENÃO escreva (“O aluno está reprovado”) FIM_SE FIM_SE fim.

Sempre que um bloco de instruções dentro de uma estrutura de seleção for executado, os demais blocos serão desconsiderados. Vejamos um exemplo: Se a média for 8.0, ou seja, maior do que 6.5, será executado o bloco da linha 11. Depois de executar esse bloco, a execução do algoritmo passará para a linha 18, ou seja, os blocos das linhas 12 a 17 não serão executados. Vejamos outras situações: Se a média for 5.5: Ao verificar a condição SE (media >= 6.5) obteremos como resultado o valor falso, situação em que será executado o primeiro SENÃO (linha 12). Ao executar o bloco de instruções deste SENÃO, haverá uma nova condição a ser verificada, SE (media >= 5). Nesse caso, o resultado será verdadeiro, devendo executar o bloco de instruções logo abaixo, exibindo a mensagem “O aluno está em exame”.

Análise e desenvolvimento de sistemas em Foco

43

Se a média for 4,0: Ao verificar a condição SE (media >= 6,5) o resultado será falso, situação em que será executado o primeiro SENÃO (linha 12). Ao executar o bloco de instruções deste SENÃO, haverá uma nova condição a ser verificada, SE (media >= 5), onde, novamente, o resultado será falso. A execução avançará para o próximo SENÃO (linha 15), que executará o bloco de instruções, exibindo a mensagem “O aluno está reprovado”.

1.2 ESTRUTURAS DE REPETIÇÃO As estruturas de repetição, também conhecidas por laços ou looping, possibilitam que uma sequência de comandos seja executada reiteradas vezes, até que determinada condição de interrupção seja atendida. Dentre os tipos de estruturas de repetição destacam-se: Enquanto-faça; Para-faça e Repita-até, os quais serão aprofundados na sequência.

44 1.2.1 Enquanto-faça Essa estrutura de repetição é também conhecida por loop pré-testado, pois a condição para sua execução é verificada logo no início, ou seja, se a condição resultar falso, as instruções que estão dentro do bloco não serão executadas nenhuma vez. Ressalta-se que nessa estrutura de repetição, toda vez que a execução chegar ao fim do bloco, retornará para o início da própria estrutura e verificará novamente se a condição é verdadeira. Se for, executa novamente o referido bloco de instruções. Vamos a um exemplo, onde o bloco de instruções será executado diversas vezes, até que o usuário informe que não deseja mais continuar.

Análise e desenvolvimento de sistemas em Foco

1 2 3 4 5 6 7 8 9 0 1 2 3 4

Algoritmo EnquantoFaca; var continuar: Caractere; Inicio Escreva (‘Informe “s” para continuar ou outro caractere para sair: ’); Leia (continuar); Enquanto (continuar = ‘s’) faça Inicio Escreva (‘Você quis continuar!’); Escreva (‘Informe “s” para continuar ou outro caractere para sair: ’); Leia (continuar); Fim Escreva (‘Você não quis continuar!’); Fim.

45

1.2.2 Para-faça A estrutura Para-faça é a mais simples das estruturas de repetição, uma vez que permite que um bloco de instruções seja executado reiteradas vezes, conforme quantidade predeterminada. Portanto, deve-se saber o número de vezes que o bloco de instruções será executado, definindo-se um limite inferior e outro superior, além da variável de controle, a qual será incrementada ou decrementada, conforme a necessidade. Vejamos um exemplo: 1 2 3 4 5 6 7 8 9

Algoritmo ParaFaca; var i: Inteiro; Inicio Para i := 1 até 10 faça Inicio Escreva (i); Fim Fim.

Análise e desenvolvimento de sistemas em Foco

1.2.3 Repita-até É uma estrutura de repetição que tem por função repetir um determinado bloco de comandos até que a condição se torne verdadeira. Ao contrário das demais estruturas de repetição, o Repita-até testa a condição somente ao final, executando, desta forma, pelo menos uma vez o bloco de instruções nele contido. Vejamos um exemplo:

46

1 2 3 4 5 6 7 8 9 0

Algoritmo RepitaAte; var Idade : Inteiro; Inicio Repita Escreva (‘Qual a sua idade: ’); Leia(Idade); Escreva(‘A idade informada é: ‘, Idade); Até (Idade = 0); Fim.

1.3 VETORES UNIDIMENSIONAIS Como se sabe, a variável é um “local na memória do computador”, que recebe um nome e possibilita o armazenamento de um valor por vez. Contudo, algumas situações exigem o armazenamento de vários valores concomitantemente, ocasião em que o desenvolvedor poderá fazer uso dos vetores, ou seja, uma variável dividida em vários “compartimentos”, onde cada compartimento é identificado por meio de um número, referente à posição de uma determinada informação no vetor em questão, sendo que o número de cada posição é denominado de índice. Vejamos a representação visual de como é estruturado um vetor. Para tanto, tomaremos como exemplo um vetor que possibilite o armazenamento de vários Nomes.

Análise e desenvolvimento de sistemas em Foco

FIGURA 2 – REPRESENTAÇÃO GRÁFICA DO VETOR UNIDIMENSIONAL

FONTE: O autor (2016)

Conforme representado no exemplo acima, temos uma única “caixa”, denominada Nomes com vários “compartimentos” numerados, sendo que cada um permite apenas a inserção de um único elemento, mas que deverão ser do mesmo 47 tipo de dados, ou seja, se a variável vetor for do tipo Caractere, cada compartimento receberá apenas valores do tipo Caractere, se a variável for do tipo Inteiro, todos os compartimentos deverão receber valores do tipo Inteiro. A utilização de vetores em nossos algoritmos implicará consequentemente na utilização de estruturas de repetição, com vistas a possibilitar a navegação, tanto para a leitura quanto para a inserção dos elementos em cada compartimento do vetor. Vejamos um exemplo:

Análise e desenvolvimento de sistemas em Foco

1 2 3 4 5 6 7 8 9 0 1

Algoritmo Vetor_ParaFaca; var Nomes : Vetor [1..4] de Caractere; i : Inteiro; Início Para i := 1 até 4 faça Início Escreva (‘Informe o ‘,i,’° nome: ‘); Leia(Nomes[i]); Fim Fim.

1.4 MATRIZES

48

Matriz (array multidimensional) é um vetor de vetores. No nosso exemplo anterior, imagine uma matriz para armazenar quatro notas para cada um dos nomes. Ou seja, um vetor de quatro posições, e em cada posição do vetor há outro vetor com quatro posições, sendo que cada item do vetor (matriz) é acessado por um número chamado de índice. Para a melhor compreensão do conceito de matrizes, veja o algoritmo abaixo, o qual tem por finalidade permitir a inclusão de quatro nomes e de quatro notas para cada nome e, ao final, apresentar a média de cada um.

Análise e desenvolvimento de sistemas em Foco

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

Algoritmo Media var nomes: vetor [1..4] de caractere; notas: vetor [1..4,1..4] de real; medias: vetor [1..4] de real; i, j: inteiro Inicio //Leitura dos nomes e das notas Para i := 1 ate 4 faça Inicio Escreva (“Informe o nome da posição ”, i, “: ”); Leia (nomes[i]); Para j := 1 ate 4 faça Inicio Escreva (“Informe a nota ”, j, " para o nome ", nomes[i], “: ”); Leia (notas[i, j]) Fim //Cálculo das médias medias[i] := (notas[i, 1] + notas[i, 2] + notas[i, 3] + notas[i, 4]) / 4 Fim //Apresentação dos resultados Para i := 1 ate 5 faça Inicio SE medias[i] >= 6 ENTAO ESCREVA (“O aluno ”, nomes[i], ” foi aprovado com as notas (“, notas[i 1], ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e média: ", medias[i]) SENAO ESCREVA (“O aluno ”, nomes[i], ” foi reprovado com as notas (“, notas[i, 1], ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e média: ", medias[i]) Fim Fim.

Análise e desenvolvimento de sistemas em Foco

49

1.5 LISTAS ENCADEADAS Na lista encadeada, cada elemento inserido na estrutura será alocado de forma dinâmica na memória. Consequentemente, o espaço total de memória utilizado pela estrutura será proporcional ao número de elementos nela armazenados, diferentemente do que ocorre em um vetor, que reservará o espaço físico na memória, independentemente do número de elementos inseridos. De acordo com Deitel e Deitel (2003, p. 62): Criar e manter estruturas de dados dinâmicas exige alocação dinâmica de memória – a capacidade de um programa obter mais espaço de memória durante a execução para armazenar novos nodos e liberar espaço não mais necessário. [...] O limite para alocação dinâmica de memória pode ser tão grande quanto à quantidade de memória física disponível no computador ou a quantidade de espaço disponível em disco em um sistema de memória virtual. Frequentemente, os limites são muito menores, porque a memória disponível do computador deve ser compartilhada entre muitos aplicativos.

50

Outra característica interessante do processo de alocação dinâmica é que não podemos afirmar que os elementos armazenados na lista ocuparão um espaço de memória contíguo, isto quer dizer um ao lado do outro. Logo, não há possibilidade de acesso direto aos elementos da lista. Para que seja possível percorrer todos os elementos da lista, devemos explicitamente armazenar o encadeamento dos elementos. Desta forma, armazena-se a informação de cada elemento juntamente com um ponteiro para o próximo elemento da lista. A figura a seguir ilustra o arranjo da memória de uma lista encadeada.

Análise e desenvolvimento de sistemas em Foco

FIGURA 3 – REPRESENTAÇÃO DO ARRANJO DA MEMÓRIA DE UMA LISTA ENCADEADA

FONTE: O autor

A estrutura consiste numa sequência encadeada de elementos, comumente denominada de nós da lista. A lista é representada por um ponteiro para o primeiro elemento (ou nó), a partir do qual se pode ascender ao segundo, seguindo o encadeamento, e assim por diante. O último elemento da lista aponta para NULL, indicando que não há mais elementos na lista. Para exemplificar a implementação de listas encadeadas em Java, vamos considerar um exemplo simples em que queremos armazenar o nome e o peso de uma pessoa numa lista encadeada. O nó da lista pode ser representado pela estrutura a seguir: FIGURA 4 – ESTRUTURA EM JAVA REPRESENTANDO O NÓ DA LISTA ENCADEADA

FONTE: O autor

A classe PessoaLista trata-se de uma estrutura autorreferenciada, pois, além dos campos que armazenam as informações (nome e peso), há o atributo (prox) que é um ponteiro para uma próxima estrutura do mesmo tipo. Normalmente, o acadêmico fica confuso em relação a isso, como se esse código fosse gerar um laço infinito, ou uma recursão infinita. No entanto, não é o caso, já que a declaração do atributo prox é apenas uma referência, que não cria uma instância de PessoaLista na memória, apenas criando uma referência à referida classe já instanciada!

Análise e desenvolvimento de sistemas em Foco

51

FIGURA 5 - REPRESENTAÇÃO DA LISTA DE PESSOAS

FONTE: O autor

Importante destacar que, embora a figura acima represente as pessoas uma ao lado da outra, na memória, provavelmente elas estejam em regiões bem distintas, contudo, cada uma delas sabe dizer em que local se encontra a próxima pessoa, já que há a referência ao próximo pelo atributo prox.

52

O código-fonte exibido acima não é a melhor forma de implementar uma lista, tendo em vista que há uma confusão de responsabilidades, onde a classe PessoaLista, além de armazenar informações sobre uma pessoa, armazena também uma lista de pessoas. Logo, manipulá-la pode ficar estranho e muito trabalhoso, já que há a necessidade de manter constantemente uma referência para a primeira pessoa na memória em algum outro lugar, o que também pode ser confuso, além de violar o conceito de coesão. Ademais, sendo necessário criar uma lista encadeada de produtos, por exemplo, ao invés de reaproveitar o código existente, prática comum na programação orientada a objetos, será necessário criar uma nova classe, denominada ProdutoLista, semelhante com a PessoaLista. Neste sentido, para criar uma estrutura mais funcional, utiliza-se uma classe separada como “nós”, evitando mesclar a classe de dados (Pessoa) da nossa estrutura.

1.6 PILHAS A estrutura de dados denominada pilha admite a remoção e inserção de novos elementos de forma dinâmica na memória, sujeitando-se à seguinte regra de operação: o elemento a ser removido será sempre o que está na estrutura há menos tempo.

Análise e desenvolvimento de sistemas em Foco

A pilha é uma versão limitada de uma lista encadeada – novos nodos podem ser adicionados a uma pilha e removidos de uma pilha apenas na parte superior (topo). Por essa razão, a pilha é conhecida como uma estrutura de dados último a entrar, primeiro a sair (last-in, first-out - LIFO). O membro de link do nodo inferior (isto é, o último) da pilha é configurado como nulo para indicar a base da pilha (DEITEL; DEITEL, 2003, p. 56).

Neste sentido, as pilhas têm muitas aplicações interessantes, principalmente na análise de expressões e sintaxe, como no caso das calculadoras que utilizam a Notação Polonesa Reversa, que implementam a estrutura de dados de pilha para expressar seus valores, podendo ser representadas de forma prefixa, pós-fixa ou infixa, ou ainda, os compiladores de muitas linguagens de programação ao realizar a análise sintática de expressões e blocos de programas. Existem duas funções que se aplicam a todas as pilhas: PUSH, que insere um dado no topo da pilha, e POP, que remove o item no topo da pilha, conforme exemplo que segue abaixo. FIGURA 6 – REPRESENTAÇÃO GRÁFICA DE UMA PILHA

FONTE: O autor

Análise e desenvolvimento de sistemas em Foco

53

1.7 FILAS No dia a dia, estamos acostumados com as filas em diversos lugares: nos bancos, nos mercados, nos hospitais, nos cinemas, entre outros. As filas são importantes, pois elas determinam a ordem de atendimento das pessoas. As pessoas são atendidas conforme a posição delas na fila. O próximo a ser atendido é o primeiro da fila. Quando o primeiro da fila é chamado para ser atendido a fila “anda”, ou seja, o segundo passa a ser o primeiro, o terceiro passa a ser o segundo e assim por diante até a última pessoa.

Normalmente, para entrar em uma fila, uma pessoa deve se colocar na última posição, ou seja, no fim da fila. Desta forma, quem chega primeiro tem prioridade. Assim como Listas e Pilhas, as Filas são estruturas de dados que armazenam os elementos de maneira sequencial.

54

As estruturas de dados denominadas Filas são estruturas do tipo FIFO (first-in, first-out), ou seja, o primeiro elemento a ser inserido será o primeiro a ser retirado, assim sendo, adiciona-se itens no fim e remove-se do início. FONTE: Caelum (2014, p. 2)

A fila é semelhante a uma fila de caixa em um supermercado – a primeira pessoa na fila é atendida primeiro e os outros clientes entram na fila apenas no final e esperam ser atendidos. Os nodos da fila são removidos apenas do início (ou cabeça) da fila e são inseridos somente no final (ou cauda) da fila (DEITEL; DEITEL, 2003, p. 72).

Segundo Deitel e Deitel (2003), as filas podem ser usadas em diversas aplicações computacionais, haja vista que a maioria dos computadores tem apenas um único processador, logo, apenas um aplicativo pode ser atendido por vez. Desta forma, os pedidos dos outros aplicativos são colocados em uma fila, onde cada pedido avança gradualmente para o início da fila à medida que os aplicativos vão sendo atendidos.

Análise e desenvolvimento de sistemas em Foco

São exemplos de uso de fila em um sistema: • Controle de documentos para impressão (spool de impressão). • Troca de mensagem entre computadores numa rede (pacotes de informações). • Solicitações de acesso a arquivos em uma rede.

1.8 ANÁLISE E TÉCNICAS DE ALGORITMOS 1.8.1 Divisão e Conquista A técnica de divisão e conquista consiste em três passos básicos, quais sejam: 1. Divisão: Dividir o problema original em subproblemas menores. 2. Conquista: Resolver cada subproblema recursivamente. 3. Combinação: Combinar as soluções encontradas, compondo uma solução única para o problema original. Para que a estratégica de divisão e conquista possa ser utilizada com sucesso deve ser possível decompor uma instância em subinstâncias; a combinação dos resultados deve ser eficiente e as subinstâncias devem ser mais ou menos do mesmo tamanho. A utilização da referida técnica é adequada em problemas que apresentam um grupo de operações que são correlacionadas ou repetidas, como, por exemplo, na multiplicação de matrizes ou, ainda, problemas em que uma decisão deve ser tomada e, uma vez tomada, quebra o problema em peças disjuntas. Em especial, a abordagem por divisão e conquista é interessante quando algumas partes passam a ser irrelevantes (TOFFOLO, 2012).

Análise e desenvolvimento de sistemas em Foco

55

Algoritmo Genérico 1 2 3 4 5 6 7 8 9 0

DivisaoeConquista(x) SE x é pequeno ou simples ENTÃO Resolver (x) SENÃO Decompor x em conjuntos menores x0; x1 ... xn PARA i := 0 até n FAÇA y1 := DivisaoeConquista(x1) i := 1+i Combinar yis Imprime (y)

Exemplo: O problema consiste em localizar o maior elemento de um vetor A [1..n]

56

Solução Simples

Solução com Divisão e Conquista

Max (A [1..n]) Maior := A [1] Para i := 2 até n faça Se A [j] > maior então Maior := A[i] Imprime (maior)

Max (A [x..y]) Se x – y >= 1 então Imprime max (A[x], A[y]) Senão m := x+y / 2 v1 := Max (A [x..m]) v2 := Max (A [m + 1 .. y] Imprime Max (v1, v2)

Dentre os algoritmos que adotam o paradigma da divisão e conquista, temos a Busca Binária, o Algoritmo da Mediana, o Algoritmo de Karatsuba e Ofman, o Mergesort e o Quicksort, sendo estes dois últimos os mais conhecidos e utilizados. • QuickSort: O algoritmo, publicado pelo professor C.A.R. Hoare em 1962, baseia-se na ideia simples de partir um vetor (ou lista a ser ordenada) em dois subvetores, de tal maneira que todos os elementos do primeiro vetor sejam menores ou iguais a todos os elementos do segundo vetor. Estabelecida a divisão, o problema estará resolvido, pois aplicando recursivamente

Análise e desenvolvimento de sistemas em Foco

a mesma técnica a cada um dos subvetores, o vetor estará ordenado ao se obter um subvetor de apenas um elemento (LAUREANO, 2008, p. 111). • MergeSort: é um algoritmo de ordenação por intercalação. Cria uma sequência ordenada a partir de duas outras também ordenadas. Para isso, o algoritmo divide a sequência original em pares de dados, ordena-as; depois as agrupa em sequências de quatro elementos, e assim por diante, até ter toda a sequência dividida em apenas duas partes (LAUREANO, 2008, p. 112).

1.8.2 Método Guloso Consiste em iniciar uma busca local a partir de várias soluções geradas aleatoriamente, com a expectativa de que haja um caminho de melhoria de custo partindo de uma dessas soluções até uma solução ótima ou próxima do ótimo (CUNHA; TAKAHASHI; ANTUNES, 2012). Os algoritmos gulosos são aqueles que, a cada decisão, sempre escolhem a alternativa que parece mais promissora naquele momento, sendo que após a decisão tomada não a reconsidera, sendo que para realizar a escolha que parece ser a melhor a cada iteração, a escolha é realizada de acordo com um critério “guloso”, ou ainda, “solução ótima”. A construção da melhor solução pressupõe a existência de um conjunto ou lista de candidatos, dos quais são acumulados um conjunto de candidatos considerados e escolhidos, e o outro de candidatos considerados e rejeitados. Posteriormente há uma função que verifica se um conjunto particular de candidatos produz uma solução (sem considerar otimalidade no momento). Outra função verifica se um conjunto de candidatos é viável, também sem se preocupar com a otimalidade, uma função de seleção indica a qualquer momento quais dos candidatos restantes é o mais promissor e, por fim, uma função objetiva fornecer o valor da solução encontrada.

Análise e desenvolvimento de sistemas em Foco

57

A função de seleção é geralmente relacionada com a função objetivo, sendo que, se o objetivo é maximizar, provavelmente escolherá o candidato restante que proporcione o maior ganho individual; se for minimizar, então será escolhido o candidato restante de menor custo. Normalmente, algoritmos gulosos são utilizados para resolver problemas de otimização que funcionem através de uma sequência de passos, como, por exemplo, o problema da mochila fracionária (ROMAN, 2013). O problema da mochila fracionária pode ser resolvido por um algoritmo guloso muito eficiente, conforme segue abaixo: Dados os vetores (x1,x2,…,xn) e (p1,p2,…,pn), denotaremos por x · p o produto escalar de x por p. Portanto, x · p = x1p1 + x2p2 + … + xnpn . Diremos que um vetor (x1,x2,…,xn) é racional se todos os seus componentes forem números racionais e natural se todos os seus componentes forem números naturais.

58

Dados os vetores naturais (p1, p2, … , pn), (v1, v2, … , vn) e um número natural c encontrar um vetor racional (x1, x2, … , xn) que maximize x · v sob as restrições x · p ≤ c e 0 ≤ xi ≤ 1 para todo i. Diremos que (p1,…,pn) é o vetor de pesos, que (v1,…,vn) é o vetor de valores e que c é a capacidade do problema. Diremos que uma mochila fracionária viável é qualquer vetor racional (x1,…,xn) tal que x · p ≤ c e 0 ≤ xi ≤ 1 para todo i. O valor de uma mochila x é o número x · v. Nosso problema é encontrar uma mochila viável de valor máximo. Motivação: Imagine que tenho n objetos que eu gostaria de colocar em uma mochila de capacidade c. Cada objeto i tem peso pi e valor vi. Posso escolher uma fração (entre 0% e 100%) de cada objeto para colocar na mochila. Quero fazer isso de modo a respeitar a capacidade da mochila e maximizar o seu valor. Exemplo: Suponha c = 50 e n = 4. A figura abaixo dá os valores de p e v. Mais abaixo, temos uma solução x do problema da mochila fracionária. O valor dessa solução é x · v = 1040.

Análise e desenvolvimento de sistemas em Foco

p

40

30

20

10

20

v

840

600

400

100

300

x

1

1/3

0

0

0

O seguinte algoritmo guloso resolve o problema da mochila fracionária. O algoritmo exige que os dados estejam em ordem crescente de valor específico (ou seja, valor por unidade de peso): v1/p1 ≤ v2/p2 ≤ … ≤ vn/pn (se pi=0 então vi/pi é infinito). É nesta ordem mágica que está o segredo do funcionamento do algoritmo.

1 2 3 4 5 6 7 8 9 0

Mochila-Fracionária (p, v, n, c) j←n enquanto j ≥ 1 e pj ≤ c faça xj ← 1 c ← c − pj j←j−1 se j ≥ 1 então xj ← c/pj para i ← j−1 decrescendo até 1 faça xi ← 0 devolva

Eis uma organização mais compacta do código:

1 2 3 4 5 6

Mochila-Fracionária (p, v, n, c) para j ← n decrescendo até 1 faça se pj ≤ c então xj ← 1 c ← c − pj senão xj ← c/pj c←0 devolva x

Análise e desenvolvimento de sistemas em Foco

59

O algoritmo é guloso porque, em cada iteração, abocanha o objeto de maior valor específico dentre os disponíveis, sem se preocupar com o que vai acontecer depois. O algoritmo jamais se arrepende do valor atribuído a um componente de x. Por que o algoritmo dá a resposta correta? É evidente que o algoritmo produz uma mochila fracionária viável; o difícil é provar que ela tem valor máximo. A prova se apoia no seguinte par de propriedades: 1 Se vn/pn ≥ vi/pi para todo i, então existe uma mochila viável de valor máximo (x1,…,xn) tal que xn = min(1, c/pn). 2 Se (x1,…,xn) é uma mochila viável de valor máximo para a instância dada do problema, então (x1,…,xn−1) é uma mochila viável de valor máximo para a instância definida pelos parâmetros n−1 e c − xnpn. FONTE: Norton T. Roman (2013)

60

1.8.3 Programação Dinâmica A Programação Dinâmica (PD) pode ser caracterizada como um processo sequencial de tomada de decisões, onde uma decisão ótima global pode ser obtida através da otimização de subproblemas (ou ótimos locais) individuais, seguindo o “princípio de otimalidade de Bellman” (DIAS et al., 2010). Na Programação Dinâmica resolvem-se os problemas de pequena dimensão e guardam-se as soluções em tabelas dinâmicas, a fim de evitar redundância de cálculo, ou seja, uma solução parcial obtida somente é calculada uma única vez. Este procedimento é importante porque, diferentemente da técnica de divisão e conquista, aqui cada subproblema é dependente de pelo menos um outro. A solução final é obtida combinando as soluções dos problemas menores (ROSA, 2011). Pode-se dizer que a Programação Dinâmica é uma maneira esperta de transformar recursão em iteração, daí ser chamada de Otimização Recursiva.

Análise e desenvolvimento de sistemas em Foco

Aplica-se quando uma estratégia ótima para resolver um problema continua a ser ótima quando este é subproblema de um problema maior, ou seja, somente soluções ótimas dos subproblemas podem compor uma solução ótima do problema original (RIBEIRO, 1999). FONTE: Disponível em: . Acesso em: 30 maio 2016.

61

Análise e desenvolvimento de sistemas em Foco

Análise e desenvolvimento de sistemas em Foco

-------------- [ TÓPICO 4 - BANCO DE DADOS RELACIONAL ] -------------Caro(a) acadêmico(a), neste capítulo vamos relembrar alguns dos principais conceitos relacionados ao tema de Banco de dados relacional. Os mesmos serão apresentados de forma sintetizada, porém não menos elucidativa, visando oferecer ao acadêmico um conteúdo importante para sua vida acadêmica e profissional. O desenvolvimento deste capítulo será feito em forma de tópicos e relambraremos os seguintes itens: Introdução ao banco de dados relacional, conceitos do modelo entidade-relacionamento, cardinalidade de relacionamentos, graus de relacionamentos, tipos de entidade, padrão SQL para banco de dados relacional, selecionando dados: DQL - data query language, funções em SQL e combinação de consultas. Vamos então iniciar os estudos, empregando o máximo de atenção e foco para que os resultados sejam os melhores possíveis, contribuindo para o incremento e fixação dos seus conhecimentos! 63 Profª. Neli Miglioli Sabadin

1 INTRODUÇÃO AO BANCO DE DADOS RELACIONAL Um banco de dados relacional é um banco de dados percebido por seus usuários como uma coleção de variáveis de relações, ou, falando de uma maneira mais informal, tabelas, que são formadas por linhas e colunas. Rezende (2006) afirma que um banco de dados é uma coleção de dados inter-relacionados, representando informações sobre um domínio específico, ou seja, sempre que for possível agrupar informações que se relacionam e tratam de um mesmo assunto, temos então um banco de dados. Da mesma forma que na matemática podem ser efetuadas operações entre dois ou mais conjuntos, em outras palavras, o modelo relacional representa uma tentativa de descrever um banco de dados através de conceitos matemáticos simples e conhecidos (álgebra relacional). A álgebra relacional contém oito operadores,

Análise e desenvolvimento de sistemas em Foco

agrupadas em dois grupos. O grupo de operadores tradicionais (União, Interseção, Diferença e Produto Cartesiano) e os relacionais especiais de restrição (Restrição, Projeção, Junção e Divisão).

Para maiores informações, veja DATE, C. J. capítulo 6 ou no site

Um banco de dados deve proporcionar uma visão abstrata para o usuário. Uma preocupação que o usuário não deve ter é qual unidade de armazenamento foi utilizada para guardar seus dados, contanto que os mesmos estejam disponíveis no momento em que ele precisar.

64

Modelo conceitual: É o primeiro nível de abstração, é onde se irá descrever quais informações devem ser armazenadas no banco de dados. Durante essa fase são apresentadas as relações, sem se preocupar em descrever como elas efetivamente serão armazenadas. A abordagem Entidade-Relacionamento (ER) é a técnica mais utilizada para essa documentação. No próximo tópico detalharemos um pouco mais. FIGURA 1 - EXEMPLO DE MODELO CONCEITUAL

FONTE: Disponível em: . Acesso em: 27 mar. 2016.

Análise e desenvolvimento de sistemas em Foco

Modelo lógico: Esta fase é mais próxima do especialista em BD, neste momento já se deve saber do Sistema de Gerenciamento de Banco de Dados (SGBD) que será utilizado. E a documentação é feita de forma mais descritiva, com o nome e a definição das colunas que formam sua estrutura. Forma de representação do modelo lógico: Aluno (Nro_mat_aluno, nom_aluno, end_aluno) Turma (cod_turma, nro_sala, período_aula). Modelo físico: Nesta fase o modelo já está diretamente ligado à escolha do SGBD, que foi escolhido pelo profissional responsável. Já se encontra o detalhamento físico das estruturas dos dados, como o tipo dos dados, tamanhos dos campos que serão armazenados no banco de dados. Exemplo: CREATE TABLE ALUNO (NRO_MAT_ALUNO NUMBER(5) PRIMARY KEY, NOM_ALUNO VARCHAR2(50), END_ALUNO VARCHAR2(50));

Análise e desenvolvimento de sistemas em Foco

65

FIGURA 2 - MODELO DE DADOS CONCEITUAL DE ALTO NÍVEL E PROJETO DE BASE DADOS

66

FONTE: Takai et al. (2005, p. 22)

Análise e desenvolvimento de sistemas em Foco

2 CONCEITOS DO MODELO ENTIDADE-RELACIONAMENTO O objeto básico que o MER representa é a Entidade. Uma entidade é algo do mundo real que possui uma existência independente, pode ser um objeto com uma existência física, como uma pessoa, ou pode ser um objeto com existência conceitual, como um curso universitário. Cada entidade tem propriedades particulares, chamadas Atributos, que a descrevem. Por exemplo, uma entidade pessoa pode ser descrita pelo seu nome, a sua data de nascimento, endereço e filiação. Uma entidade em particular terá um valor para cada um de seus atributos. Em alguns casos, alguns atributos podem ser divididos em subpartes com significados independentes, chamados de atributos compostos (TAKAI et al., 2005, p. 24). As chaves, em relação ao modelo lógico, correspondem aos atributos identificadores. Eles permitem dar uma identificação a cada ocorrência de instância em uma tabela, e garantir que elas sejam únicas. Há outras funcionalidades, sendo que, além de ter a função de identificar uma linha de uma tabela, elas ajudam a estabelecer o relacionamento entre as tabelas de um banco de dados relacional. Basicamente existem três tipos de chaves em um banco de dados relacional: CHAVE PRIMÁRIA, CHAVE ESTRANGEIRA e CHAVE ÚNICA. A chave primária ou primary key (PK) é uma coluna ou conjunto de colunas que identificam unicamente (ou seja, não se repete) um registro dentro de uma tabela, ela pode ser simples ou composta. Os campos que pertencem à chave primária são obrigatórios, não admitindo valor vazio ou NULL. A chave estrangeira ou foreign key (FK) é uma coluna ou conjunto de colunas que se referem necessariamente a uma chave primária de outra tabela ou dela mesma no caso de recursividade, estabelecendo um relacionamento entre as tabelas. Este relacionamento garante a integridade dos dados relacionados, pois apenas serão permitidos valores que atendam ao relacionamento. Chave única ou chave alternativa - em alguns casos, mais de uma coluna ou grupo de colunas da tabela servem para identificar unicamente um registro. Neste caso, uma das chaves é criada como chave primária e a outra como alternativa (também conhecida como Chave única “UK”).

Análise e desenvolvimento de sistemas em Foco

67

3 CARDINALIDADE DE RELACIONAMENTOS É o número máximo e mínimo de ocorrências de uma entidade que estão associadas às ocorrências de outra entidade que participa do relacionamento. Ou seja, a cardinalidade é importante para ajudar a definir o relacionamento, pois ela define o número de ocorrências em um relacionamento. • UM-PARA-UM (1 : 1): uma entidade A (nesse caso, paciente) está associada no máximo a uma entidade em B (prontuário) e uma entidade em B está associada no máximo a uma entidade em A. Nesse exemplo, um paciente só pode ter um prontuário e um prontuário só pode pertencer a um paciente.

FIGURA 3 - RELACIONAMENTO 1:1

68

FONTE: Disponível em: >. Acesso em: 4 abr. 2016.

• MUITOS-PARA-UM (N : 1): uma entidade em A (nesse caso, venda) está associada no máximo a uma entidade em B (cliente), enquanto uma entidade em B está associada a qualquer número de entidades em B. Nesse exemplo, uma venda só pode ser realizada para um único cliente, mas um cliente pode participar de várias vendas. • MUITOS-PARA-MUITOS: Uma entidade em A está associada a qualquer número de entidades em B, e uma entidade em B está associada a qualquer número de entidades em A. FIGURA 4 - RELACIONAMENTO M:M

Análise e desenvolvimento de sistemas em Foco

FIGURA 5 - RELACIONAMENTO M: 1

FONTE: Disponível em: . Acesso em: 4 abr. 2016.

4 GRAUS DE RELACIONAMENTOS Pode ser classificado como BINÁRIO (associação entre duas entidades), como apresentado na Figura 7, ou TERNÁRIO (associação entre duas ou mais entidades).

FIGURA 6 - RELACIONAMENTO TERNÁRIO

69

FONTE: Disponível em: . Acesso em: 4 abr. 2016.

Análise e desenvolvimento de sistemas em Foco

AGREGAÇÃO: Uma limitação do modelo E-R é que não é possível expressar relacionamentos entre relacionamentos. Agregação é uma abstração através da qual relacionamentos são tratados como entidades de nível superior. GENERALIZAÇÃO E ESPECIALIZAÇÃO: Existem casos em que um conjunto-entidade pode ser dividido em categorias, cada qual com atributos específicos.

FIGURA 7 - AGREGAÇÃO

70

FIGURA 8 – ESPECIALIZAÇÃO OU GENERALIZAÇÃO

FONTE: Disponível em: . Acesso em: 4 abr. 2016.

Análise e desenvolvimento de sistemas em Foco

AUTORRELACIONAMENTO: Este tipo de relacionamento ocorre toda vez que temos uma ocorrência de uma entidade que está associada a uma ou mais ocorrências da mesma entidade. Ou seja, temos uma entidade onde suas ocorrências possuem relacionamentos entre si. Os autorrelacionamentos são, na verdade, uma forma de representarmos relações de hierarquia entre ocorrências de uma mesma entidade. Por exemplo, vamos considerar uma entidade EMPREGADO, sendo que no modelo conceitual devemos representar o conceito de que um empregado possui um gerente. Ou seja, existe um relacionamento entre as ocorrências da entidade EMPREGADO que estabelece que um empregado é gerente de outro empregado.

FIGURA 9 - AUTORRELACIONAMENTO

71

FONTE: Disponível em: . Acesso em: 4 abr. 2016.

5 TIPOS DE ENTIDADES Um modelo de dados contém diferentes tipos de entidades que são diferenciadas pelo formato dos identificadores. A classificação de cada uma dessas entidades pelo tipo ajudará você a definir quais perguntas devem ser feitas.

Análise e desenvolvimento de sistemas em Foco

ENTIDADE TIPO: Representa um conceito independente em um modelo de dados e está em primeiro lugar na mente do cliente. As entidades tipo são independentes e, com frequência, constituem o ponto de partida de um modelo de dados. As entidades tipo muitas vezes estão conectadas a outras entidades tipo por meio de um relacionamento 1:m ou m:m. Para exemplificar, podemos considerar um sistema acadêmico onde as entidades aluno e curso são entidades tipo, pois a entidade aluno, se não existisse a entidade curso, poderia existir da mesma forma.

72

ENTIDADE FRACA OU DEPENDENTE: Uma entidade fraca (ou dependente) precisa de outra entidade para garantir a sua existência. A entidade fraca depende de uma entidade TIPO e esta relação de dependência é uma relação obrigatória. O identificador de uma entidade fraca possui em sua composição o(s) atributo(s) identificador(es) da entidade TIPO à qual a entidade fraca está associada. Como exemplo, podemos considerar um sistema de gestão de recursos humanos onde a entidade dependente é uma entidade fraca em relação à entidade funcionário. Pois se a entidade Funcionários não existisse, a entidade dependente consequentemente não existiria. ENTIDADE ASSOCIATIVA: As entidades associativas são o resultado de relacionamentos m:m. Em geral, as entidades associativas são encontradas entre entidades tipo. Muitas das vezes, as entidades associativas têm nomes óbvios, pois ocorrem no mundo real. Por exemplo, a entidade associativa do relacionamento disciplinas e alunos, objetivando o lançamento de notas, chama-se avaliação. Deve-se sempre procurar pelo nome adequado, pois esse irá aumentar a clareza do modelo de dados. ENTIDADE AGREGADA: Cria-se uma entidade agregada quando temos um conjunto de atributos que aparecem em mais de uma entidade do modelo de dados. Ou seja, quando várias entidades distintas têm atributos em comum. Nestes casos devemos criar uma entidade agregada contendo os atributos que se repetem em mais de uma entidade. Por exemplo, como os atributos de um endereço podem ocorrer em entidades diferentes (CLIENTES E FORNECEDORES, por exemplo), pode-se criar uma entidade agregada ENDEREÇOS para armazenar detalhes de todos os endereços.

Análise e desenvolvimento de sistemas em Foco

ENTIDADE SUBORDINADA: Uma entidade representa uma especialização de entidade no modelo de dados onde uma entidade supertipo possui várias entidades subordinadas que são especializadas com atributos específicos. Devemos usar entidades subordinadas toda vez que tivermos entidades que compartilham conceitos semelhantes, mas que possuem características próprias. Por exemplo, podemos ter uma entidade supertipo CLIENTE contendo os atributos codigo, nome, endereco e telefone e duas entidades subordinadas PESSOA FISICA e PESSOA JURIDICA contendo atributos específicos respectivamente nro_cpf e nro_cnpj. Tanto PESSOA FISICA como PESSOA JURIDICA compartilham conceitos semelhantes, ambas possuem um nome e endereco, mas possuem também características próprias, pois PESSOA FISICA possui nro_cpf e PESSOA JURIDICA possui nro_cnpj. FONTE: Disponível de: . Acesso em: 4 abr. 2016.

73 6 PADRÃO SQL PARA BANCO DE DADOS RELACIONAL É difícil desvincular a história da linguagem SQL (Structured Query Language) da história do banco de dados relacional. Através dos comandos SQL os usuários podem montar consultas poderosas, sem a necessidade da criação de um programa, podendo utilizar ferramentas front-end para a montagem de relatórios. A linguagem SQL é adotada por praticamente todos os SGBDs relacionais existentes no mercado, além de ser uma linguagem padronizada (ANSI). É uma linguagem utilizada para banco de dados relacionais, baseada e inspirada em álgebra relacional. Utiliza como subconjuntos principais o DML, DDL, DCL, DTL e DQL. DML - Data Manipulation Language (Linguagem de Manipulação de Dados): É utilizado para realizar inclusões, consultas, exclusões e alterações de dados. Utiliza os comandos INSERT, SELECT, UPDATE e DELETE. DDL - Data Definition Language (Linguagem de Definição de Dados): Permite definir tabelas e elementos associados. Utiliza como comandos principais o CREATE e o DROP, alguns sistemas de banco de dados utilizam o ALTER.

Análise e desenvolvimento de sistemas em Foco

Ex.: CREATE TABLE nome_tabela (nome_campo tipo_do campo). DCL - Data Control Language (Linguagem de Controle de Dados): Controla os aspectos de autorização de dados e a utilização de licenças por usuários. Os principais comandos são GRANT e REVOKE. DTL - Data Transaction Language (Linguagem de Transação de Dados): Utilizado pelos desenvolvedores em transações. Os principais comandos são COMMIT e ROLLBACK. DQL - Data Query Language (Linguagem de Consulta de Dados): O mais importante dentre estes, pois consultas são realizadas a todo instante. O comando que é utilizado pelo DQL é o SELECT. Em algumas literaturas, o SELECT também aparece como um comando. Na linguagem SQL são empregados os termos tabela, coluna, linha, para designar, respectivamente, relação, atributo e tupla. 74

7 SELECIONANDO DADOS: DQL - DATA QUERY LANGUAGE Podemos selecionar colunas específicas de uma tabela, segundo o modelo: SELECT FROM Para recuperar todas as colunas de uma tabela substitui-se por *, conforme apresentado: SELECT * FROM ; Nos modelos de seleção apresentados acima estamos selecionando todos os registros da tabela. Mas também podemos selecionar apenas alguns registros da tabela, utilizando o comando WHERE: SELECT FROM WHERE ; A cláusula WHERE tem a seguinte forma: WHERE .

Análise e desenvolvimento de sistemas em Foco

Vale ressaltar que o pode ser substituído por ( = igual, ou != diferente, < menor que, > maior que, >= maior ou igual a,) que descrevem cada elemento da página. Adicionar tags descritivas a um documento é conhecido como “marcar” o documento – Páginas Web utilizam uma linguagem de marcação conhecida como HyperText Markup Language (HTML), que foi criada especialmente para documentos com links de hipertexto. O HTML apresenta inúmeros elementos de texto para compor documentos, como cabeçalhos, parágrafos, texto e os links. Também permite incrementar a informação do documento através de componentes para criação de formulários, imagens, mídias.

Análise e desenvolvimento de sistemas em Foco

105

Documentos HTML: São várias as versões HTML existentes atualmente. A versão atual é HTML5. O HTML é uma linguagem para estruturar e apresentar conteúdos de páginas web. A versão 5 traz novas funcionalidades muito importantes, relacionadas à semântica e acessibilidade. Acoplou recursos que antes só poderiam ser usados através da adoção de outras tecnologias. O HTML5 traz tags de vídeo e áudio, inexistentes em versões anteriores. As etiquetas HTML são case sensitive. Ou seja, não há diferença nas formas de escrita: , ,  ou . Todas são reconhecidas. As etiquetas básicas de HTML presentes nas páginas são: • : determina o início de um documento HTML; • : especifica o cabeçalho de um documento HTML; • : é o corpo do documento HTML. O cabeçalho apresenta os seguintes componentes: 106

• • • • •

: mostra o título da página; : define o formato CSS; : permite a adição de funções de JavaScript; : liga a página com outros arquivos, como feeds, CSS, scripts etc.; : faz a descrição da página, autor, etc.

Os campos citados são usados por mecanismos de busca (como o  Google,  Yahoo!,  Bing) e servem de filtro para calcular a similaridade dos documentos e oferecer ao usuário um resultado mais próximo de suas reais necessidades. Para o Google, apenas  e a meta  são usadas para descrever a página indexada numa busca. As etiquetas  e  servem para invocar códigos de arquivos externos. Dentro do corpo existem várias etiquetas para modelar a página:

Análise e desenvolvimento de sistemas em Foco

• • • •

, , ... : para cabeçalhos e títulos; : novo parágrafo; : quebra de linha; : cria uma tabela. Os cabeçalhos das colunas são criados com as etiquetas  e os rodapés com ); • : determina divisões na página; • , ,  e : negrito, itálico, sublinhado e riscado; • : imagem; • : ligação para uma página, um e-mail ou outro serviço; • : caixa de texto (com mais de uma linha); • : abreviação; • : citação; • :Endereço. Exemplo de código HTML Testando a página Teste Outro teste de página Texto sublinhado

Inserindo Imagens: Arquivos HTML não contêm imagens. Elas ficam em arquivos separados e são colocadas entre o texto através do elemento IMAGE do HTML. O elemento IMAGE indica ao navegador a URL da imagem (endereço para exibição). Ao encontrar o elemento IMG, o navegador faz uma nova solicitação ao servidor, para retornar a imagem. O mesmo acontece com vídeos e outros arquivos de mídias distintas. Embora elaborada e montada em partes, ela retorna completa e de forma rápida. Em conexões mais lentas os textos podem aparecer antes das imagens.

Análise e desenvolvimento de sistemas em Foco

107

Estilos: No início da página encontram-se os links que apontam para o documento de folhas de estilo, que indica como a página aparecerá no navegador. Apresenta instruções escritas em CSS (Cascading Style Sheets) que permitem aos designers das telas elaborarem o estilo visual da página, através do texto de marcação. Adicionando Comportamento: além de definir a estrutura e a cara da página, também é possível definir o comportamento da mesma, através da linguagem Javascript. O comportamento é definido e alterado através da programação.

108

Web Sites x Web Apps: atualmente não há consenso sobre onde termina um website e começa um web app. Antes dos apps os sites web forneciam interações avançadas aos usuários usando softwares previamente instalados. Exemplo: webmail, Google maps etc. A web apps permite experiências mais ricas e satisfatórias dos usuários, possibilitando acesso avançado aos navegadores. Um web app é sempre voltado para tarefas, para fazer alguma coisa. Em celulares, por exemplo, podemos citar a localização de um táxi, restaurante ou a própria realização de uma chamada telefônica. Para entender melhor: websites são lidos. Web apps são para leitura e escrita. Websites são consumidos. Web apps permitem criar. Rich Internet Application (RIA): significa aplicação de internet rica. É uma aplicação Web que se parece muito com software de aplicação desktop. Muito utilizada para jogos nos navegadores (sons, vídeos, movimentos, gráficos). É concorrente do HTML5. Computação em Nuvem: a computação em nuvem permite o armazenamento, acesso e compartilhamento de informações através da internet. Baseia-se no conceito de informação em qualquer hora e lugar. Os dados armazenados são acessados a qualquer hora de qualquer lugar do mundo, sem a necessidade de instalação de tecnologia específica para isso. O acesso aos dados é remoto, não sendo necessárias as instalações físicas. Para acesso, basta que o computador tenha a configuração mínima de acesso à internet. Web Server: são os servidores de internet. São programas de computador que interpretam as solicitações HTTP de computadores clientes, para devolver uma resposta. São usados para hospedar os sites da Web. Podem também ser usados

Análise e desenvolvimento de sistemas em Foco

para armazenar dados, executar aplicativos, e-mail, FTP para transferência de arquivos, entre outros. Web servers mais conhecidos: • • • •

Apache Tomcat da Apache – http://tomcat.apache.org Internet Information Server (IIS) da Microsoft – http://www.iis.net Google Web Server (GWS) da Google Glassfish da Oracle

XML (eXtensible Markup Language): gera linguagens de marcação para necessidades especiais. Faz parte do conjunto de subtipos do SGML (Standard Generalized Markup Language). Seu objetivo é descrever distintos tipos de dados, facilitando o compartilhamento dos mesmos através da internet. O XHTML é uma das linguagens XML. O XML define o formato de páginas web, criando uma estrutura única para várias linguagens. Vantagens do uso do XML: • É um padrão formal de desenvolvimento. • Está associado ao W3C, instituição de padronização mundialmente reconhecida. 109 • Tem como base as experiências de desenvolvimento do SGML. • O texto é simples e facilita o entendimento. Suporta o formato Unicode. • Através do XML é possível implementar listas, árvores e registros, comuns em outras linguagens de programação, inclusive a programação estruturada. • Apresenta boa documentação e se autodocumenta, através de seu formato. • Os algoritmos XML são mais rápidos e eficientes. • É editável em editores txt antigos. Os editores atuais destacam o XML (tag, conteúdo e atributos). Desvantagens: Geralmente estão associados a implementações de menor complexidade, como vetores e listas, onde os desenvolvedores podem optar por formatos mais simples, avaliando dentre outros itens como velocidade e editabilidade. XHTML (eXtensible Hypertext Markup Language), combina as tags de marcação HTML com regras da XML, permitindo a exibição de uma página web em diversos formatos, como televisão, palmtop, celular, além de melhorar o acesso ao conteúdo.

Análise e desenvolvimento de sistemas em Foco

Cascading Style Sheets (CSS) é uma linguagem que trabalha com folhas de estilo na apresentação de documentos que são escritos em linguagem de marcação. Ela separa o formato do conteúdo. Os programadores criam links para páginas que contêm os estilos ao invés de incorporá-los no documento. Isso cria um padrão para todas as páginas. Para alterar a aparência, altera-se apenas um arquivo, facilitando a manutenção. JAVA: Java é uma plataforma que agrega várias tecnologias para desenvolvimento web, inclusive a linguagem de que leva o próprio nome Java. É uma tecnologia orientada a objetos que surgiu na década de 1990, desenvolvida pela empresa SUN Microsystems. A linguagem Java é compilada por um bytecode que é executado por uma máquina virtual.

• • • 110 •

• • • •

Foi projetada para atender aos seguintes critérios: Ser orientada a objetos. Ser portável, ou seja, não ter dependência da plataforma. Facilitar a comunicação em rede através dos protocolos TCP/IP, HTTP e FTP. Oferecer segurança. Vantagens: A escrita do código é parecida com as linguagens C e C++. É fácil de ser especificada. Possui várias bibliotecas (APIs) que facilitam o desenvolvimento dos aplicativos. Facilita o desenvolvimento de aplicativos distribuídos.

WEB DESIGN: Através da web design é possível criar websites e outros documentos que estarão disponíveis em servidores para internet. Web design é multidisciplinar, pois exige conhecimento de várias áreas, além dos conhecimentos técnicos do próprio design. Envolve programação, ergonomia, arquitetura das informações, criatividade, inovação, ousadia. Preocupa-se com a experiência do usuário final no que tange à acessibilidade e ergonomia, para garantir que o mesmo atinja seus objetivos através de uma experiência satisfatória na página.

Análise e desenvolvimento de sistemas em Foco

O profissional web designer é o responsável pela parte estética e funcional dos sites. Ele deve ter domínio de várias tecnologias: HTML/XHTML, CSS, JavaScript/ DHTML, Flash etc. ASP: (Active Server Pages) é uma estrutura de bibliotecas. Não pode ser considerada uma linguagem. Processa linguagens de script no servidor. Opera com linguagens como VBScript, JScript ou Python. Roda em Windows Server através do serviço ISS (Internet Information Services). Também roda em Linux, com servidor Apache. PHP: A linguagem PHP foi criada em 1994. Em 1995 seu código-fonte foi liberado. Seu nome significa Personal Home Page. É uma linguagem modularizada, amplamente utilizada em servidores web. Sua sintaxe é muito parecida com as linguagens C e C++. É uma linguagem pública e de código aberto. JSP: é uma tecnologia usada para criar páginas web em HTML e XML, permitindo acesso ao banco de dados, além da manipulação de arquivos texto. Uma página criada nesta tecnologia e instalada em um servidor de aplicação que seja compatível com a plataforma Java EE é transformada em um Servlet. As páginas 111 são carregadas dentro do servidor e processadas pelo Java EE Web Application. A sintaxe do JSP é uma mistura de dois tipos básicos de conteúdo: scriptlet elements e mark-up. Mark-up é um padrão do HTML ou XML, sendo que os elementos scriptlet são blocos de código Java que podem ser unidos com o mark-up. APACHE: é um servidor. Também conhecido por HTTP Apache. É o mais conhecido e utilizado servidor para web. Foi desenvolvido em 1995. É compatível com o protocolo HTTP e suporta mais da metade de todos os sites existentes. ISS: é o servidor web da Microsoft. É uma plataforma para a hospedagem de sites, serviços e aplicativos. Integra facilmente as tecnologias: ASP. NET,  FTP,  PHP,  WCF e o próprio ISS. Permite a geração de páginas HTML dinâmicas, através de tecnologia proprietária (ASP). Sua instalação requer licença de uso. Reduz o consumo do servidor, aumentando a segurança na rede. Utiliza o protocolo FTP para que seja possível carregar e baixar arquivos. MYSQL: É um SGBD (Sistema Gerenciador de Banco de Dados), que utiliza a linguagem de consulta estruturada (SQL). Tem alta portabilidade, suportando

Análise e desenvolvimento de sistemas em Foco

praticamente todas as plataformas atuais. É rápido e estável. Permite o uso de triggers, procedures e funções de banco. Tem um eficiente controle de transações. É amplamente utilizado. SQL: se divide em dois grupos principais, os comandos destinados à definição de dados (DDL – Data Definition Language) e os comandos destinados à manipulação de dados (DML – Data Manipulation Language). • O phpMyAdmin é a ferramenta de administração de banco de dados MySQL disponibilizada no XAMPP, e permite criação dos objetos do banco de dados sem a necessidade de escrever os comandos DDL. JEE: é a plataforma JAVA para redes. Contém bibliotecas (APIs) desenvolvidas especificamente para acesso a servidores. Altamente escalável (muitos usuários acessando ao mesmo tempo). JSF: Java Server Faces é o framework padrão da Java para criação de sites com tecnologia JEE. Funciona baseado em objetos que são guardados na 112 memória do servidor, responsáveis por gerar o código HTML para o navegador. Pertence à arquitetura MVC. JPA: O JPA pertence à tecnologia JAVA EE e fornece um conjunto de interfaces e classes usadas em aplicativos desenvolvidos em Java. O JPA faz a persistência de estado das classes Java. É responsável pela criação das tabelas na base de dados e mapeamento do objeto relacional (ORM). O JPA permite a persistência do estado de qualquer classe Java, bastando para tal colocar as anotações obrigatórias. O JPA fica responsável pela criação das tabelas no banco de dados e posteriores operações de mapeamento objeto relacional. ORM: Técnica utilizada para tratar as incompatibilidades entre os modelos relacional e orientados a objetos. EJB: (Enterprise Java Beans) – é um componente da plataforma JEE que roda em containers de servidores de aplicação que encapsula a lógica. Tem como foco a lógica do problema a ser resolvido. Foi criado para permitir um desenvolvimento rápido e seguro de aplicativos em Java.

Análise e desenvolvimento de sistemas em Foco

Entity Beans são objetos que persistem em uma base de dados. Os Session Beans executam tarefas para os clientes (solicitantes). O Message Driven Beans processa as mensagens entre os EJBs. CDI: responsável pela injeção de dependência quando é necessário manter baixo nível de acoplamento entre as distintas partes de um sistema. STATELESS SESION BEANS: é um bean de sessão sem a informação de estado, pois não mantém comunicação com muitos métodos para com os seus clientes. STATEFULL SESSION BEAN: é um bean de sessão com informações de estado. Ou seja: controlam o estado do usuário. Dão suporte aos processos de negócio que precisam de várias solicitações ou transações ao mesmo tempo. SINGLETON BEANS: Pode ser considerado o terceiro tipo de bean. É uma instanciação de uma classe com um único acesso global. 113

Análise e desenvolvimento de sistemas em Foco

Análise e desenvolvimento de sistemas em Foco

----------------------- [ TÓPICO 7 - GESTÃO DE PROJETO ] ----------------------Caro(a) acadêmico(a), neste capítulo vamos relembrar os assuntos referentes à área de Gerência de Projetos, com suas dez áreas de conhecimentos. Os assuntos serão apresentados de forma sintetizada, através dos objetivos e das principais atividades do Gerente de Projetos, o qual é responsável por planejar e controlar a execução de projetos em diversas áreas de atuação, entre outros, como, no nosso caso, o desenvolvimento de software.  Portanto, mostraremos técnicas, ferramentas e metodologias que possibilitam ao gestor uma maior padronização e controle na execução dos projetos. Antes de começarmos a nossa revisão, os conceitos são apresentados segundo o guia PMBOK do PMI (PROJECT MANAGEMENT INSTITUTE, 2013), lembrando que apresentaremos uma versão reduzida e abordaremos as áreas de conhecimento. Sugerimos que você aprofunde seus estudos para melhores resultados. Profª. Neli Miglioli Sabadin

115

1 INTRODUÇÃO Antes de começarmos a nossa revisão, os conceitos são apresentados segundo o guia PMBOK do PMI (PROJECT MANAGEMENT INSTITUTE, 2013), lembrando que apresentaremos uma versão reduzida e abordaremos as áreas de conhecimento.

Sugerimos que você aprofunde seus estudos para melhores resultados no ENADE. Acesse:

Análise e desenvolvimento de sistemas em Foco

Projeto, segundo a definição proposta pelo PMI (2013), é um esforço temporário aplicado para criar um produto, serviço ou resultado único. O conceito é de temporário, pois ele tem um começo e um fim definido, o que não significa que deva ser obrigatoriamente curto ou longo. O término é alcançado quando os objetivos do projeto são atingidos ou quando o projeto é encerrado porque os seus objetivos não serão ou não podem ser alcançados, ou quando a necessidade do projeto deixar de existir, ou pela solicitação do cliente para o encerramento. Um projeto pode envolver uma única pessoa ou muitas pessoas, uma única organização ou múltiplas unidades organizacionais de múltiplas organizações (PMI, 2013). “GERENCIAMENTO DE PROJETOS é a aplicação de conhecimentos, ferramentas e habilidades para ter sucesso nos projetos” (PMI, 2013, p. 4). Ele normalmente inclui (mas não se limita) a identificação dos requisitos, a abordagem das diferentes necessidades, preocupações e expectativas das partes interessadas no planejamento e execução do projeto e o estabelecimento, manutenção e execução de comunicações ativas, eficazes e colaborativas entre as partes interessadas. O gerenciamento das partes interessadas visando o atendimento aos requisitos do projeto e a criação das suas entregas. Além 116 do equilíbrio das restrições conflitantes do projeto, que incluem (mas não se limitam) o Escopo, Qualidade, Cronograma, Orçamento, Recursos e Riscos. Vale ressaltar que as características e circunstâncias específicas do projeto podem influenciar as restrições nas quais a equipe de gerenciamento do projeto precisa se concentrar (PMI, 2013). O Guia PMBOK (que é a base desse resumo) tem seu alicerce no plano PDCA, que, segundo Vaz (2015), é também chamado de Ciclo de Deming ou Ciclo de Shewhart, e consiste em uma ferramenta de gestão que objetiva promover a melhoria contínua dos processos por meio de um circuito de quatro ações: planejar (Plan), fazer (Do), checar (Check) e agir (Act). O intuito é ajudar a entender não só como um problema surge, mas também como deve ser solucionado, focando na causa e não nas consequências. Uma vez identificada a oportunidade de melhoria, é hora de colocar em ação atitudes para promover a mudança necessária e, então, atingir os resultados desejados com mais qualidade e eficiência. Esse método de análise e de mudança de processos parte do pressuposto de que o planejamento não é uma fase estanque — ou seja, não acontece uma única vez, tampouco é

Análise e desenvolvimento de sistemas em Foco

absoluta. Por isso, no decorrer do projeto pode ser preciso mudar o planejamento. E o Ciclo PDCA ajuda a fazer exatamente esse controle, que é contínuo, contribuindo para que cada processo se desenvolva da melhor maneira possível.

Para maiores informações, acesse:

Segundo o Guia PMBOK (2013), o gerenciamento de projetos é a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos. Ele é realizado através da aplicação e integração apropriadas dos 47 processos de gerenciamento de projetos, logicamente agrupados em cinco grupos de processos. Esses cinco grupos de processos são: Iniciação, Planejamento, Execução, Monitoramento e Controle, e Encerramento. Esses cinco grupos, segundo Medeiros (2013), são aplicados em áreas de conhecimento. Uma área de conhecimento é definida por seus 117 requisitos de conhecimentos e descrita em termos dos processos que a compõem, suas práticas, entradas, saídas, ferramentas e técnicas. Existem nove áreas de conhecimento, são elas: Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicações, Riscos e Aquisições.

2 PARTES INTERESSADAS E PMO Um Escritório de Gerenciamento de Projetos (EGP ou, em inglês, PMO) é uma estrutura organizacional que padroniza os processos de governança relacionados a projetos, e facilita o compartilhamento de recursos, metodologias, ferramentas e técnicas. As responsabilidades de um PMO podem variar, desde o fornecimento de funções de apoio ao gerenciamento de projetos, até a responsabilidade real pelo gerenciamento direto de um ou mais projetos. Há vários tipos de estruturas de PMO nas organizações, e elas variam em função do seu grau de controle e influência nos projetos da organização, tais como: SUPORTE, CONTROLE e DIRETIVO (PMBOK, 2013, p. 10).

Análise e desenvolvimento de sistemas em Foco

As partes interessadas têm diversos níveis de responsabilidade e autoridade quando participam de um projeto, segundo o Guia PMBOK (2013), os quais podem mudar ao longo do ciclo de vida do projeto. E a participação das partes interessadas pode ser efetiva ou pontual, apenas. A identificação das partes interessadas é um processo contínuo em todo o ciclo de vida do projeto, bem como a compreensão do seu grau relativo de influência em um projeto e o balanceamento das suas exigências, necessidades e expectativas são fundamentais para o sucesso de um projeto. As partes interessadas do projeto incluem: STAKEHOLDER - para Bezerra (2014), significa público estratégico e descreve uma pessoa ou grupo que fez um investimento ou tem ações ou interesse em uma empresa, negócio ou indústria. Em inglês stake significa interesse, participação, risco; holder significa aquele que possui. Assim, stakeholder também significa parte interessada ou interveniente. É uma palavra em inglês muito utilizada nas áreas de comunicação, administração e tecnologia da informação, cujo objetivo é designar as pessoas e grupos mais importantes para um planejamento estratégico ou plano de negócios, ou seja, as partes interessadas. 118

PATROCINADOR: É uma pessoa ou grupo que fornece recursos e suporte para o projeto e é responsável pelo sucesso do mesmo. Ele pode ser externo ou interno em relação à organização do gerente de projetos, e deve promover o projeto desde a sua concepção inicial até o seu encerramento. Ele também garante uma transferência tranquila das entregas do projeto para os negócios da organização do solicitante após o encerramento do projeto (PMBOK, 2013, p. 31). GERENTE DE PROJETOS: É a pessoa alocada pela organização executora para liderar a equipe responsável por alcançar os objetivos do projeto, seu papel é diferente de um gerente funcional ou gerente de operações. Normalmente, o gerente funcional se concentra em proporcionar a supervisão de gerenciamento de uma unidade funcional ou de negócios, e os gerentes de operações são responsáveis pela eficiência das operações de negócios. Os gerentes de projetos são responsáveis pelo atendimento de necessidades: de tarefas, necessidades de equipe e necessidades individuais. Como o gerenciamento de projetos é uma disciplina estratégica crítica, o gerente de projetos torna-se o elo entre a estratégia e a equipe (PMBOK, 2013, p. 15).

Análise e desenvolvimento de sistemas em Foco

CLIENTES E USUÁRIOS: São as pessoas ou organizações que aprovarão e gerenciarão o produto, serviço ou resultado do projeto. São eles que usarão o produto, serviço ou resultado do projeto. Da mesma maneira que o patrocinador, eles podem ser internos ou externos em relação à organização executora, e também podem existir em múltiplos níveis (PMBOK, 2013, p. 31).

VENDEDORES: “Fornecedores ou contratadas, são empresas externas que assinam um contrato para fornecimento de componentes ou serviços necessários ao projeto” (PMBOK, 2013, p. 32). PARCEIROS DE NEGÓCIOS: “São organizações externas que têm uma relação especial com a empresa, às vezes obtida através de um processo de certificação. Os parceiros de negócios fornecem consultoria especializada ou desempenham um papel específico, como instalação, personalização, treinamento ou suporte” (PMBOK, 2013, p. 31). GRUPOS ORGANIZACIONAIS: “São as partes interessadas internas afetadas pelas atividades da equipe do projeto” (PMBOK, 2013, p. 32). 119 GERENTES FUNCIONAIS: “São pessoas-chave que desempenham uma função gerencial dentro de uma área administrativa ou funcional do negócio, como recursos humanos, finanças, contabilidade ou aquisições” (PMBOK, 2013, p. 32). OUTRAS PARTES INTERESSADAS: “Como entidades de aquisições, instituições financeiras, órgãos públicos reguladores, especialistas em áreas do conhecimento, consultores e outros, podem ter um interesse financeiro no projeto, contribuir com informações para o projeto, ou ter um interesse no resultado do mesmo” (PMBOK, 2013, p. 32).

Análise e desenvolvimento de sistemas em Foco

3 OS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS Um grupo de processo é um conjunto de processos que suportam o desenvolvimento do projeto, onde “Processo é um conjunto de ações (interrelacionadas) que levam a um resultado (saídas esperadas de produtos, resultados ou serviços)”. Os grupos de processos de gerenciamento de projetos estão vinculados pelas saídas que produzem, eles raramente são eventos distintos ou que ocorrem uma única vez; são atividades sobrepostas que ocorrem ao longo de todo o projeto. A saída de um processo, em geral, torna-se uma entrada em outro processo ou é uma entrega do projeto, subprojeto ou fase do projeto. As entregas em nível de projeto ou subprojeto podem ser chamadas de entregas incrementais. O grupo de processos de planejamento fornece ao grupo de processos de execução o plano de gerenciamento do projeto e os documentos do projeto e, à medida que o projeto avança, ele frequentemente cria atualizações no plano de gerenciamento e nos documentos do projeto. A Figura 1 ilustra como os grupos de processos interagem e mostra o nível de sobreposição em diversas ocasiões. Se o projeto estiver dividido em fases, os grupos de processos interagem dentro de cada fase (PMBOK, 2013). 120 A seguir estão todos os processos de gerenciamento de projetos do Guia PMBOK Quinta Edição, agrupados por área de conhecimento e grupos de processos:

Análise e desenvolvimento de sistemas em Foco

FIGURA 1 - GRUPO DE PROCESSOS DE GERENCIAMENTO DE PROJETOS E MAPEAMENTO DAS ÁREAS DE CONHECIMENTO

121

FONTE: Adaptado de PMI (2013, p. 61)

Observa-se na Figura 2 que os processos interagem entre si, e quase que durante todo o projeto. O processo de iniciação, por exemplo, interage com os processos de planejamento, os processos de planejamento interagem com os processos de execução, e assim por diante. Isso significa, por exemplo, que temos processos de iniciação que geram saídas para os processos de planejamento (PMBOK, 2013).

Análise e desenvolvimento de sistemas em Foco

FIGURA 2 - INTERAÇÃO ENTRE OS PROCESSOS

FONTE: PMBOK (2013, p. 419)

122

Processos de uma mesma área também podem gerar saídas para serem entradas para processos da mesma área. Portanto, os processos, de alguma forma, se relacionam uns com os outros. A aplicação dos processos também pode ser iterativa, ou seja, na medida em que o projeto vai se desenvolvendo, alterações vão sendo feitas nos processos. Às vezes, inclusive o planejamento do projeto precisa ser alterado devido alguma mudança requerida pelo cliente, e isso teria como efeito revisitar os processos de planejamento, tendo como saída um novo planejamento do projeto. Assim, verificamos que os mesmos processos são abordados novamente, isso nos remete a essa iteratividade nos processos. FONTE: Disponível em: . Acesso em: 3 abr. 2016.

Análise e desenvolvimento de sistemas em Foco

4 ÁREAS DE CONHECIMENTO Uma área de conhecimento, segundo o PMI, é definida por seus requisitos de conhecimentos e descrita em termos dos processos que a compõem, suas práticas, entradas, saídas, ferramentas e técnicas. Existem nove áreas de conhecimento, são elas: INTEGRAÇÃO, ESCOPO, TEMPO, CUSTOS, QUALIDADE, RECURSOS HUMANOS, COMUNICAÇÕES, RISCOS E AQUISIÇÕES E PARTES INTERESSADAS (PMBOK, 2013). 4 - INTEGRAÇÃO (estes números se referem ao capítulo do PMBOK 5ª edição) Colocando de maneira resumida, o Guia PMBOK (2013) afirma que o gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de processos de gerenciamento. Nesta área de conhecimento, o gerente do projeto age como integrador dos processos e das pessoas. Descrevem-se os processos que integram elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados 123 dentro dos grupos de processos de gerenciamento de projetos. Os processos dessa área são: • • • • • •

Desenvolver o termo de abertura do projeto. Desenvolver o plano de gerenciamento do projeto. Orientar e gerenciar o trabalho do projeto. Monitorar e controlar o trabalho do projeto. Realizar o controle integrado de mudanças. Encerrar o projeto ou fase.

Apresentaremos uma adaptação do resumo dos processos realizada pelo site Escritório de projetos, referente à quinta edição do Guia PMBOK.

Análise e desenvolvimento de sistemas em Foco

O gerenciamento da integração define onde e quando concentrar recursos e esforços, tratando problemas antes de se tornarem críticos e coordenando o trabalho visando sempre o sucesso do projeto. Alguns aspectos a serem considerados: • Os processos de controle de mudanças estão alinhados com as diretrizes de controle de mudanças do PMO? • As metas e os objetivos do projeto estão evidenciados no plano do projeto? • Avaliar de maneira integrada qualquer necessidade de replanejamento. • Usar o plano de gerenciamento das comunicações para garantir informações disponíveis para as áreas necessárias.

Descrevendo os processos do gerenciamento da integração do projeto: 4.1 Desenvolver o termo de abertura do projeto: Fase em que se deve autorizar um projeto ou fase e documentar requisitos iniciais. 4.2 Desenvolver o plano de gerenciamento do projeto: Identificar as 124 ações necessárias para definir, preparar, integrar e coordenar planos auxiliares. 4.3 Orientar e gerenciar o trabalho do projeto: realizar trabalho definido no plano de projeto para atingir os objetivos do projeto. 4.4 Monitorar e controlar o trabalho do projeto: O Gerente vai acompanhar e revisar o progresso para atender aos objetivos de desempenho definidos no plano do projeto. 4.5 Realizar o controle integrado de mudanças: Faz-se a revisão das solicitações de mudança, a aprovação e gerenciamento de mudanças. 4.6 Encerrar o projeto ou fase: Fase em que se finaliza todas as atividades de gerenciamento do projeto para terminar o projeto ou a fase.

Análise e desenvolvimento de sistemas em Foco

5 ESCOPO Esta área descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário e apenas o trabalho necessário, para que seja concluído com sucesso. Durante essa etapa preocupa-se, principalmente, em DEFINIR E CONTROLAR O QUE ESTÁ INCLUSO NO PROJETO E O QUE NÃO ESTÁ. Descrevendo os processos do gerenciamento do escopo do projeto: 5.1 Planejar o gerenciamento do escopo: Aqui se define e documenta-se como a equipe do projeto IRÁ DEFINIR, CONTROLAR E VALIDAR O ESCOPO. 5.2 Coletar os requisitos: Fase em que o GP define e documenta as necessidades das partes interessadas para atingir os objetivos do projeto. 5.3 Definir o escopo: Deve-se desenvolver a descrição detalhada do projeto e do produto. 5.4 Criar a EAP (Estrutura Analítica do Projeto): Subdivide os produtos do projeto e o trabalho do projeto em componentes menores e mais gerenciáveis. A EAP é fundamental para o projeto, pois fornece uma visão estruturada do que será entregue, facilitando o entendimento das partes interessadas em relação ao que deve ser feito (escopo) no projeto, além de servir de base para o planejamento das 125 outras áreas de conhecimento. 5.5 Validar o escopo: Nesta etapa formaliza-se a aceitação dos produtos do projeto. 5.6 Controlar o escopo: O GP monitora o status do escopo do projeto e do produto e gerencia as alterações na linha de base de escopo.

6 TEMPO Segundo o Guia PMBOK®, o gerenciamento do tempo inclui os processos requeridos para assegurar a conclusão do projeto no prazo previsto. Esta área descreve os processos relativos ao término do projeto no prazo correto. Os cinco primeiros processos são de planejamento e apenas o último é de controle. Os processos de planejamento definem as atividades que vão

Análise e desenvolvimento de sistemas em Foco

para o cronograma, a ordem de precedência das atividades, determinam o tipo e a quantidade de recursos necessários, o tempo necessário para concluir as atividades, associam as atividades às datas do cronograma e, por fim, verificam se o andamento dos trabalhos está de acordo com o cronograma.

Descrevendo os processos do gerenciamento do tempo do projeto: 6.1 Planejar o gerenciamento do cronograma: Fase em que se estabelecem políticas, procedimentos para planejar, desenvolver, gerenciar e controlar o cronograma. 6.2 Definir as atividades: Identificar as atividades específicas que devem ser executadas para produzir as entregas do projeto são atividades desenvolvidos nesta fase. 6.3 Sequenciar as atividades: Fase em que se deve identificar e documentar as relações de dependência entre as atividades. 6.4 Estimar os recursos das atividades: O GP estima o tipo e quantidade dos recursos necessários para executar cada atividade. 126 6.5 Estimar as durações das atividades: Após estimar os recursos, deve-se estimar a quantidade de períodos de trabalho que serão necessários para completar cada atividade. 6.6 Desenvolver o cronograma: Analisar a sequência das atividades, sua duração, seus recursos e suas restrições para criar o cronograma do projeto são atividades que são realizadas nesta etapa. 6.7 Controlar o cronograma: Mudanças sempre ocorrem e o GP deve controlar as mudanças no cronograma.

“Leva nove meses para uma mulher gerar um bebê. Não se pode gerar um bebê em um mês engravidando nove mulheres”.

Análise e desenvolvimento de sistemas em Foco

7 CUSTO O gerenciamento dos custos do projeto inclui os processos envolvidos em estimativas, orçamentos e controle dos custos, de modo que o projeto possa ser terminado dentro do orçamento aprovado. Onde os primeiros dois processos são de planejamento, e temos que os processos nesta área de conhecimento determinam o custo de cada atividade levando em consideração o recurso alocado na atividade, além dos períodos de trabalho que o recurso estará trabalhando na atividade, determinam que os custos de cada atividade sejam somados a fim de gerar uma linha de base de custos, e acompanham a execução para verificar se as coisas estão ocorrendo conforme o orçamento definido.

Descrevendo os processos do gerenciamento dos custos do projeto: 7.1 Planejar o gerenciamento dos custos: Estabelecer as políticas, procedimentos e documentação para planejar, gerenciar, executar e controlar os custos do projeto. 7.2 Estimar os custos: Estimar os custos dos recursos necessários para 127 executar as atividades do projeto. 7.3 Determinar o orçamento: Agregar os custos estimados das atividades para estabelecer uma linha de base. 7.4 Controlar os custos: Monitorar o status do projeto para atualizar o orçamento e gerenciar alterações na linha de base dos custos.

8 QUALIDADE O Gerenciamento da Qualidade em Projetos busca assegurar que o projeto satisfaça as necessidades do cliente e envolve todas as atividades do projeto por todo o seu ciclo de vida. Ele implementa o sistema de gestão da qualidade por meio de políticas e procedimentos com atividades de melhoria contínua de processos. O GP deve conscientizar toda a equipe sobre a importância de buscar os objetivos da qualidade, e para isso deve oferecer as condições necessárias para que o time possa alcançá-los.

Análise e desenvolvimento de sistemas em Foco

Descrevendo os processos do gerenciamento da qualidade do projeto: 8.1 Planejar o gerenciamento da qualidade: Identificar os requisitos e/ ou padrões da qualidade do projeto e do produto, bem como documentar de que modo o projeto demonstrará a conformidade. 8.2 Realizar a garantia da qualidade: Processo de auditoria dos requisitos da qualidade e dos resultados das medições do controle da qualidade para certificar que os padrões da qualidade e definições operacionais apropriadas estão sendo utilizados. 8.3 Controlar a qualidade: Processo de monitoramento e registro dos resultados da execução das atividades da qualidade para avaliar a performance e recomendar mudanças necessárias.

9 RECURSOS HUMANOS

128

Segundo o Guia PMBOK®, o gerenciamento dos recursos humanos do projeto inclui os processos que organizam e gerenciam a equipe do projeto. Os processos desta área de conhecimento têm como objetivo determinar os tipos e o perfil dos profissionais, além da hierarquia desses profissionais e quem é responsável pelo o que no projeto quando ele estiver em execução; determinam como mobilizar as pessoas que foram requisitadas no projeto; se preocupam com o treinamento da equipe, além da integração e geração de conhecimento, e determinam como resolver conflitos antes que eles afetem o projeto. A equipe é composta por pessoas com funções e responsabilidades atribuídas com foco no término do projeto.

Descrevendo os processos do gerenciamento dos recursos humanos do projeto: 9.1 Planejar o gerenciamento dos recursos humanos: Identificar e documentar as funções, responsabilidades, competências necessárias e relações hierárquicas. Cria o plano de gerenciamento de RH. 9.2 Mobilizar a equipe do projeto: Obter os recursos humanos necessários para o projeto.

Análise e desenvolvimento de sistemas em Foco

9.3 Desenvolver a equipe do projeto: Melhorar as competências e interação dos membros da equipe para aprimorar o desempenho do projeto. 9.4 Gerenciar a equipe do projeto: Acompanhar o desempenho da equipe, fornecer feedback, resolver problemas e coordenar mudanças para melhorar o desempenho do projeto.

10 COMUNICAÇÕES Esta área descreve os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e adequada. Segundo o Guia PMBOK®, o gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. Os processos desta área de conhecimento determinam quem está envolvido no projeto, definem como as comunicações vão ocorrer quando o projeto iniciar e determinam o tipo de informações geradas, quem é o responsável, qual o meio, quem receberá as informações geradas, qual a periodicidade, determinam como serão distribuídas as informações, como podemos gerenciar as expectativas dos interessados medindo o grau de satisfação ou insatisfação das pessoas interessadas, e geram relatórios que permitam o acompanhamento e controle do que está acontecendo com o tempo, custo, escopo etc. A comunicação certamente é uma das áreas de conhecimento mais importantes para o GP, se não for a mais importante. Ela representa cerca de 90% do tempo do GP e é o elo de ligação entre as pessoas, as ideias e as informações. Além disso, a maioria dos problemas dos projetos é oriunda de falha de comunicação e existe uma forte correlação entre o desempenho do projeto e a habilidade do GP em administrar as comunicações.

Análise e desenvolvimento de sistemas em Foco

129

Descrevendo os processos do gerenciamento das comunicações do projeto: 10.1 Planejar o gerenciamento das comunicações: identificar as necessidades e relevância de informações e definir abordagem de comunicação. 10.2 Gerenciar as comunicações: colocar as informações necessárias à disposição das partes interessadas conforme planejado. Envolve todo o ciclo de vida da informação descrito no plano de gerenciamento da comunicação, composto por gerar, coletar, distribuir, armazenar, recuperar e até descartar a informação. 10.3 Controlar as comunicações: controlar e monitorar as comunicações de modo a garantir que as necessidades de informação das partes interessadas sejam atendidas.

11 RISCOS

130

Segundo o Guia PMBOK®, o gerenciamento dos riscos do projeto inclui os processos de planejamento, identificação, análise, planejamento de respostas, monitoramento e controle de riscos de um projeto. Seu objetivo é maximizar a exposição aos eventos positivos e minimizar a exposição aos eventos negativos. Os processos desta área de conhecimento têm como objetivo determinar como os riscos serão identificados, analisados e como as respostas serão planejadas e como o risco será planejado; criam uma lista de riscos identificados no projeto com diversas técnicas que ajudam a gerar essa lista de riscos; buscam priorizar os riscos com base no grau de criticidade; permitem atribuir probabilidade numérica aos riscos; definem estratégias e ações para lidar com os riscos negativos e positivos; monitoram os riscos com novos riscos sendo identificados, revisão das análises de riscos, definição de outras prioridades de riscos etc. Risco de um projeto é um evento com uma probabilidade de ocorrer no futuro, impactando o projeto de forma negativa (ameaça) ou positiva (oportunidade). Ele pode ocorrer devido a uma ou mais causas e pode ocasionar um ou mais impactos positivos ou negativos. É importante ressaltar que os

Análise e desenvolvimento de sistemas em Foco

riscos estão relacionados com as demais áreas de conhecimento e devem ser tratados de forma integrada, considerando as melhores práticas de cada área de conhecimento.

• • • •

Os riscos podem ser: Conhecidos, foram identificados, analisados e considerados no planejamento do projeto. Desconhecidos, e nesse caso, quando o evento ocorre, temos um problema ou questão para o projeto (Issues) e devem ser tratados agilmente. O GP deve tomar as devidas ações corretivas, identificar as causas e tomar ações preventivas para que o problema não ocorra novamente. E ainda, deve documentar todas as decisões tomadas, notificar os responsáveis e garantir seu comprometimento na resolução do mesmo.

Descrevendo os processos do gerenciamento dos riscos do projeto: 11.1 Planejar o gerenciamento dos riscos: definir como conduzir as atividades de gerenciamento de riscos para o projeto. 131 11.2 Identificar os riscos: determinar quais riscos podem afetar o projeto e documentar suas características. 11.3 Realizar a análise qualitativa dos riscos: avaliar a exposição ao risco para priorizar os riscos que serão objeto de análise ou ação adicional. 11.4 Realizar a análise quantitativa dos riscos: efetuar a análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto. 11.5 Planejar as respostas aos riscos: desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. 11.6 Controlar os riscos: monitorar e controlar os riscos durante o ciclo de vida do projeto.

Análise e desenvolvimento de sistemas em Foco

12 AQUISIÇÕES Segundo o Guia PMBOK, o gerenciamento das aquisições do projeto inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto, além dos processos de gerenciamento de contratos. Os processos desta área de conhecimento têm como objetivo determinar o que se quer adquirir, de quem se quer adquirir, receber as respostas dos fornecedores e selecionar o fornecedor, como se dará o gerenciamento dos contratos, pagamentos, se as entregas estão de acordo com o que foi estabelecido, pagar o fornecedor e, por último, formalizar a finalização do contrato. O gerenciamento das aquisições do projeto é uma das áreas de conhecimento mais importantes dentro das organizações, principalmente devido ao aumento constante da terceirização de serviços.

132

As empresas precisam trabalhar no que elas fazem de melhor e deixar as demais áreas para empresas especializadas. Como afirmou Tom Peters: "Do what you do best and outsource the rest." Seus principais envolvidos são: • Vendedor = fornecedor, contratada, subcontratada, prestador de serviços ou fornecedor. • Comprador = cliente, contratante, organização compradora, órgão governamental, solicitante do serviço. Seguindo o Guia PMBOK, sempre abordará a perspectiva do comprador. Um dos principais elementos das aquisições é o contrato, documento legal entre comprador e fornecedor que descreve um acordo mútuo gerando obrigações entre as partes.

Descrevendo os processos do gerenciamento das aquisições do projeto: 12.1 Planejar o gerenciamento das aquisições: documentar as decisões de compras do projeto, especificando a abordagem e identificando fornecedores em potencial.

Análise e desenvolvimento de sistemas em Foco

12.2 Conduzir as aquisições: obter as respostas dos fornecedores, selecionar um fornecedor e redigir o contrato. 12.3 Controlar as aquisições: gerenciar as relações de aquisição monitorando o desempenho do contrato e realizando as mudanças e correções conforme necessário. 12.4 Encerrar as aquisições: finalizar todas as aquisições do projeto

13 GERENCIAMENTO DAS PARTES INTERESSADAS O gerenciamento das partes interessadas é a nova área de conhecimento do Guia PMBOK@ 5ª edição, o que reforça a importância das partes interessadas em nossos projetos. As partes interessadas (também chamadas pelo termo inglês stakeholders) são os indivíduos e as organizações ativamente envolvidos no projeto, ou seja, quem interessa no seu projeto. O projeto irá atender necessidades das partes interessadas e elas são responsáveis por atender ao objetivo do projeto. Podem ser positivamente ou negativamente afetados com a execução do projeto e irão influenciar o projeto e/ou seu resultado.

Descrevendo os processos do gerenciamento das partes interessadas do projeto: 13.1 Identificar as partes interessadas: e seus interesses, envolvimento e impacto no sucesso do projeto. 13.2 Planejar o gerenciamento das partes interessadas: desenvolver estratégias para quebrar as resistências das partes interessadas e garantir seu engajamento no projeto. 13.3 Gerenciar o engajamento das partes interessadas: comunicar e interagir com as partes interessadas para atender suas necessidades e solucionar as questões quando ocorrem. 13.4 Controlar o engajamento das partes interessadas: monitorar os relacionamentos entre as partes interessadas e ajustar as estratégias para engajar as partes interessadas, eliminando resistências e aumentando o suporte ao projeto. FONTE: Disponível em: . Acesso em: 3 abr. 2016.

Análise e desenvolvimento de sistemas em Foco

133

Análise e desenvolvimento de sistemas em Foco

REFERÊNCIAS AMARAL, Allan Francisco Forzza. Redes de Computadores. Colatina: Instituto Federal do Espírito Santo, 2012. BASTOS, Cleverson; KELLER, Vicente. Aprendendo Lógica. 1. ed. Rio de Janeiro, RJ: Vozes, 1991. BEZERRA, Filipe. Stakeholders - do significado à classificação. Disponível em: . Acesso em: 24 mar. 2016. BOENTE, Alfredo Nazareno P.; OLIVEIRA, Fabiano S. G.; ALVES, João C. N. RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software. Disponível em: . Acesso em: 26 maio 2016. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Elsevier, 2005. CAELUM. Algoritmos e estruturas de dados em java. Disponível em: . Acesso em: 10 out. 2014. CUNHA, Gaspar Antonio; TAKAHASHI, Ricardo; ANTUNES, Carlos Henggeler. Manual de computação evolutiva e meta heurostica. Coimbra: UFMG, 2012. CUNHA, Judson Michel; JUNIOR, Danton Cavalcanti Franco. Arquitetura de computadores. Indaial: Uniasselvi, 2012. DANTAS, Mário. Redes de comunicação e computadores: abordagem quantitativa. Florianópolis: Visual Books, 2010. DEITEL. Harvey M.; DEITEL. Paul J. Java, como programar. Tradução Carlos Arthur Lang Lisbôa, 4. ed. – Porto Alegre: Bookman, 2003. DIMES, Troy. Scrum Essencial. Canadá: Babelcube Inc., 2014. Disponível em: . Acesso em: 30 jun. 2015. ENGHOLM JR, Hélio. Engenharia de software na prática. 1. ed. São Paulo: Editora Novatec, 2010. ESCRITÓRIO DE PROJETOS. processos do guia PMBOK. 5. ed. Disponível em: . Acesso em: 24 mar. 2016.

Análise e desenvolvimento de sistemas em Foco

135

FERNANDES, D. B. Metodologia dinâmica para o desenvolvimento de sistemas versáteis. São Paulo: Érica, 1999. FERREIRA, Aurélio Buarque de Holanda. Dicionário da língua portuguesa. 5. ed. Curitiba: Positivo, 2010. FRANCISCANI, Juliana; PESTILI, Ligia C. CMMI e MPS.BR: um estudo comparativo. [S.1.], [S.1.]. Disponível em: . Acesso em: 27 set. 2015. GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre, Brasil: Bookman, 2000. GUIA ORACLE: Banco de dados Oracle 10g: Fundamentos de SQL I Ano 2004. Disponível em: . Acesso em: 2 mar. 2016. HIRAMA, K. Engenharia de Software: qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2011. ISO. Standards. Disponível em: . Acesso em: 20 set. 2015. 136 JUNIOR, Danton Cavalcanti Franco; GROSS, Jan Charles. Sistemas e Aplicações Distribuídas. Indaial: Uniasselvi, 2013. KOCHANSKI, D.; ANDRIETTI, O. J. Algoritmos. Indaial: Uniasselvi, 2005. KROLL, P.; KRUCHTEN, P. The rational unified process made easy: a practitioner’s guide to the RUP. Addison Wesley, 2003. KUROSE, James F.; ROSS, Keith W. Redes de computadores e a Internet: uma abordagem top-down. 5. ed. São Paulo: Pearson, 2010. LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007. LATZKE, Carlos Alberto; GROSS, Jan Charles. Infraestrutura de redes de computadores. Indaial: Uniasselvi, 2013. LAUREANO, Marcos. Estrutura de dados com algoritmos e C. São Paulo: Brasport, 2008. MEDEIROS, Higor. Áreas de conhecimento segundo o PMBOK. Disponível em: . Acesso em: 24 mar. 2016. MELO, A. C. Desenvolvendo aplicações com UML 2.2. 3. ed. Rio de Janeiro: Brasport, 2006.

Análise e desenvolvimento de sistemas em Foco

MORAES, Alexandre Fernandes de. Redes de computadores. São Paulo: Érica, 2014. PAIXÃO, Renato Rodrigues. Arquitetura de computadores – PCs. São Paulo: Érica, 2014. PFLEEGER, Shari Lawrence. Engenharia de software, teoria e prática. 2. ed. São Paulo: Pearson, 2004. PIVA, G. D. Análise e Gerenciamento de Dados. Manual de Informática Centro Paula Souza, v. 3, São Paulo, 2010. PONTUSCHKA, Maurício Nacib. Modelagem de software orientada a objetos. Disponível em: . Acesso em: 5 maio 2016. PRESSMAN, R. S. Engenharia de Software – Uma abordagem profissional. 7. ed. Porto Alegre: AMGH Editora Ltda., 2011. PRESSMAN, Roger S. Engenharia de software. 3. ed. São Paulo: McGraw-Hill, 2006. PRESSMAN, Roger S. Engenharia de software. McGraw Hill, 6. ed. Porto Alegre: 2010. PROJECT MANAGEMENT INSTITUTE – PMI Project. Um guia do conhecimento em gerenciamento de projetos - Guia PMBOK®). 5. ed. USA: Pennsylvania, 2013. REZENDE, Ricardo; Conceitos Fundamentais de Banco de Dados. 2006. Disponível em . Acesso em: 2 mar. 2016. ROMAN, Norton T. Algoritmos Gulosos. Disponível em: . Acesso em: 5 jul. 2016. ROSS, Júlio. Redes de computadores. Rio de Janeiro: Almeida e Porto, 2008. SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Addison Wesley, 2011. SOUZA, Givanaldo Rocha de. Metodologias ágeis de desenvolvimento de software. Disponível em: . Acesso em: 27 set. 2015. TAKAI, Osvaldo Kotaro et al. Introdução a banco de dados. 2005. Disponível em: . Acesso em: 24 mar. 2016.

Análise e desenvolvimento de sistemas em Foco

137

TANENBAUM, Andrew S. Redes de Computadores. 5. ed. Rio de Janeiro: Elsevier, 2003. TORRES, Gabriel. Redes de computadores: curso completo. Rio de Janeiro: Axcel Books, 2001. TUFFOLO, Túlio. Algoritmos e Estruturas de Dados I. Disponível em: . Acesso em: 5 jul. 2016. VASCONCELOS A. M. L. de et al. Introdução à engenharia de software e à qualidade de software. UFLA/FAEPE, 2006. 57 p. (Curso de Pós-graduação “Lato Sensu” (Especialização) à Distância – Melhoria de Processo de Software. VAZ, Thassia; Ciclo PDCA: uma ferramenta imprescindível ao gerente de projetos! Disponível em: . Acesso em: 24 mar. 2016. ZANCHETT, Pedro Sidnei. Engenharia e projeto de software. Indaial: Uniasselvi, 2015.

138

Análise e desenvolvimento de sistemas em Foco

139

Análise e desenvolvimento de sistemas em Foco