PROJETO, IMPLEMENTAÇÃO E TESTE DE SOFTWARE

SOFTWARE

Professora Esp. Janaína Aparecida de Freitas

GRADUAÇÃO

C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância; FREITAS, Janaína Aparecida de.

Projeto, Implementação e Teste de Software. Janaína Aparecida de Freitas.

Maringá-Pr.: UniCesumar, 2016. 223 p.

“Graduação - EaD”.

1. Projeto. 2. Implementação . 3. Software 4. EaD. I. Título. CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2

Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB-8 - 6828

Pró-Reitor de EAD

Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi

NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho

Direção de Planejamento de Ensino Fabrício Lazilha

Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira

Direção de Polos Próprios James Prestes

Direção de Desenvolvimento Dayane Almeida

Direção de Relacionamento Alessandra Baron

Head de Produção de Conteúdos Rodolfo Encinas de Encarnação Pinelli Gerência de Produção de Conteúdos Gabriel Araújo

Supervisão do Núcleo de Produção de Materiais

Nádila de Almeida Toledo Supervisão de Projetos Especiais Daniel F. Hey Coordenador de Conteúdo Fabiana De Lima Design Educacional Ana Salvadego Iconografia

Amanda Peçanha dos Santos, Ana Carolina Martins Prado

Projeto Gráfico

Jaime de Marchi Junior, José Jhonny Coelho Arte Capa

André Morais de Freitas Editoração

Matheus Felipe Davi Qualidade Textual Hellyery Agda G. Silva Naiara Valenciano Pedro Barth Ilustração

questão de sobrevivência no mundo do trabalho. Cada um de nós tem uma grande responsabilida-de: as escolhas que fizermos por nós e pelos nos-sos farão grande diferença no futuro.

Com essa visão, o Centro Universitário Cesumar assume o compromisso de democratizar o conhe-cimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros.

No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária” –, o Centro Universi-tário Cesumar busca a integração do ensino-pes-quisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consci-ência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade.

Diante disso, o Centro Universitário Cesumar al-meja ser reconhecido como uma instituição uni-versitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; con-solidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação da comunidade interna; qualidade da gestão acadêmica e administrati-va; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relaciona-mento permanente com os egressos, incentivan-do a educação continuada.

Diretoria Operacional de Ensino

inseridos. De que forma o fazemos? Criando oportu-nidades e/ou estabelecendo mudanças capazes de alcançar um nível de desenvolvimento compatível com os desafios que surgem no mundo contemporâneo. O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): “Os homens se educam juntos, na transformação do mundo”. Os materiais produzidos oferecem linguagem dialógica e encontram-se integrados à proposta pedagógica, con-tribuindo no processo educacional, complementando sua formação profissional, desenvolvendo competên-cias e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inseri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo “provocar uma aproximação entre você e o conteúdo”, desta forma possibilita o desenvolvimento da autonomia em busca dos conhecimentos necessá-rios para a sua formação pessoal e profissional. Portanto, nossa distância nesse processo de cresci-mento e construção do conhecicresci-mento deve ser apenas geográfica. Utilize os diversos recursos pedagógicos que o Centro Universitário Cesumar lhe possibilita. Ou seja, acesse regularmente o AVA – Ambiente Virtual de Aprendizagem, interaja nos fóruns e enquetes, assista às aulas ao vivo e participe das discussões. Além dis-so, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendiza-gem, possibilitando-lhe trilhar com tranquilidade e segurança sua trajetória acadêmica.

Professora Esp. Janaína Aparecida de Freitas

Bacharel em Informática pela Universidade Estadual de Maringá (2010). Especialização em MBA em Teste de Software pela Universidade UNICEUMA, Brasil. (2012). Trabalhou na iniciativa privada, na área de Analise de Sistemas e Testes de Software. Têm experiência na área de Engenharia de Software com ênfase em Análise de Requisitos, Gestão de Projetos de Software, Métricas e Estimativas, Qualidade e Teste de Software. Atualmente cursando o Técnico em Qualidade no Senac-PR e Licenciatura em Letras - Português/Inglês na UniCesumar. Atualmente é Professora Mediadora dos cursos de graduação ADS – Analise e Desenvolvimento de Sistemas e SI – Sistemas para Internet na modalidade de ensino EAD pela UniCesumar (2015).

SEJA BEM-VINDO(A)!

Prezado(a) acadêmico(a)! Seja bem-vindo(a) à disciplina Projeto, Implementação e Teste de Software. Neste curso, iremos abordar as atividades existentes no processo de desen-volvimento de software, que são as atividades que envolvem o projeto, a implementa-ção e o teste de software.

As unidades do livro foram organizadas de forma contínua, ou seja, a unidade seguinte sempre está vinculada com a unidade anterior, portanto, é bom que você leia e entenda todo o conteúdo de uma unidade para passar para a próxima.

Vamos iniciar na unidade I conhecendo os conceitos sobre as fases Projeto, Implementa-ção e Teste de Software, com o objetivo de compreender a importância destes conceitos como partes do processo de desenvolvimento do software.

Seguindo para a unidade II, vamos conhecer mais a fundo os conceitos que envolvem a fase do Projeto e compreender a sua importância e com isso entender como ele pode minimizar a distância entre o sistema e o mundo real. Vamos representar o software, fornecendo detalhes sobre o seu funcionamento, estruturas, interface e todos os com-ponentes necessários para desenvolver um sistema. Fase em que deve ser conferido e verificado se os requisitos do cliente poderão ser atendidos. No projeto é onde geramos uma descrição detalhada informando tudo o que o software deverá fazer e como este irá se comportar, sempre levando em conta o que foi levantado na análise de requisitos junto ao cliente.

Depois, na unidade II, na fase de implementação, que é o momento em que desenvol-vemos o código, vamos ver que além de ser escrito, precisamos testá-lo e depurá-lo, as-sim como compilá-lo e, por fim, ter um produto executável por completo. Durante este processo, o ideal é que se utilize um controle de versões para acompanhar as diferentes mudanças do código durante o desenvolvimento. Na fase de Implementação, vamos detalhar os componentes previstos no projeto, descrevendo todos os componentes de código fonte e código binário, em nível de linguagem de programação ou de acordo com as tecnologias escolhidas no levantamento de requisitos.

E por fim, nas unidades IV e V, vamos aprender que quando a empresa desenvolvedora de software busca por qualidade, ela percebe que é necessário investir pesado em tes-tes de software e que existem vários tipos de tes-testes-tes no mercado para atender as suas necessidades, e que pode ser preciso implantar mais de um tipo ou investir em métricas de software para garantia da qualidade destes testes. Ganhando espaço na comunidade de software, as métricas de teste de software veem conquistando e sendo de grande importância para as empresas que buscam qualidade e eficiência em seus projetos. Espero que sua leitura seja agradável e que esse conteúdo possa contribuir para seu crescimento pessoal e profissional. Vamos começar nossos estudos?

UNIDADE I

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

15 Introdução

16 Introdução ao Projeto, Implementação e Teste de Software 21 Projeto de Software 26 Implementação de Software 28 Teste de Software 32 Considerações Finais 40 Referências 41 Gabarito UNIDADE II PROJETO DE SOFTWARE 45 Introdução

46 A Fase de Projeto de Software

49 Conceitos Básicos de Projeto de Software 52 Qualidade do Projeto

54 Modelo do Projeto

55 Projeto da Arquitetura do Software 63 Projeto de Componentes

68 Projeto de Interface do Usuário

77 Projeto de Dados 80 Considerações Finais 88 Referências 89 Gabarito UNIDADE III IMPLEMENTAÇÃO DE SOFTWARE 93 Introdução 94 Implementação de Software

97 Atividades da Implementação de Software 100 Características da Implementação de Software 101 Estilo de Programação e Codificação

103 Comentários 106 Depuração

109 Asserções e Programação Defensiva 110 Otimização de Desempenho 112 Refatoração

114 Considerações Finais 123 Referências

UNIDADE IV

TESTE DE SOFTWARE

127 Introdução

128 Introdução ao Teste de Software 132 Conceitos Básicos de Teste de Software 135 Ciclo de Vida do Teste de Software 139 Técnicas de Teste de Software 145 Papéis e Cargos de Teste de Software 148 Ambiente de Teste

153 Considerações Finais 162 Referências

163 Gabarito

UNIDADE V

PROCESSO DE TESTE DE SOFTWARE

167 Introdução

168 Documentação de Teste de Software 178 Relatórios de Teste de Software

184 Validação e Verificação em Testes de Software 188 Ferramentas de Teste de Software

194 Métricas e Medição

204 Gerência de Risco em Teste de Software 213 Considerações Finais

221 Referências 222 Gabarito 223 Conclusão

UNID

ADE

I

IMPLEMENTAÇÃO E TESTES

DE SOFTWARE

Objetivos de Aprendizagem

■ Conceituar Projeto, Implementação e Teste de Software. ■ Compreender a importância desses conceitos como áreas da

Engenharia de Software.

Plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade: ■ Introdução ao Projeto, Implementação e Teste de Software ■ Projeto de Software

■ Implementação de Software ■ Teste de Software

INTRODUÇÃO

Olá, aluno(a)! Começamos nossos estudos apresentando alguns conceitos já estudados e que fazem parte do processo de software. Mostrarei a você como ele é composto de atividades que são necessárias para o desenvolvimento de um sistema. No processo de software, existem vários modelos e com algumas ativi-dades básicas, por exemplo: a análise de requisitos, o projeto, a implementação, os testes, a implantação e a manutenção. No nosso livro, vamos estudar apenas as atividades que envolvem o projeto, a implementação e o teste de software.

Nesta primeira unidade, serão apresentados os conceitos sobre as fases (ati-vidades ou etapas): Projeto, Implementação e Teste de Software, com o objetivo de compreender a importância desses conceitos como partes do processo de desenvolvimento do software.

Na fase de Projeto é onde vamos representar o software, fornecendo detalhes sobre o seu funcionamento, estruturas, interface e todos os componentes neces-sários para desenvolver um sistema. Fase onde deve ser conferido e verificado se os requisitos do cliente poderão ser atendidos. No projeto é onde geramos uma descrição detalhada informando tudo o que o software deverá fazer e como este irá se comportar, sempre levando em conta o que foi levantado na análise de requisitos junto ao cliente.

Após a fase de Projeto, passamos a fase de implementação, ou seja, a pro-gramação, a codificação do código e onde determinamos a linguagem que será usada para o desenvolvimento do sistema. Nesta fase, construímos o software baseado nas definições técnicas da fase de projeto e entramos na prática do desenvolvimento do sistema.

Na fase de testes, passamos a validar o sistema que foi implementado. Nesta fase são testados os códigos à procura de defeitos, problemas que podem ocor-rer na interface e outros que possam surgir quando o sistema é integrado.

Assim, nosso objetivo nesta unidade é entender os conceitos das etapas que envolvem o processo de software e como são relacionadas.

Vamos, portanto, aos conceitos! Boa leitura!

Introdução Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

©shutterstock Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E

TESTE DE SOFTWARE

Para compreendemos os conceitos de Projeto, Implementação e Teste de Software, é necessário que revisemos alguns conceitos do processo de software que já foram estudados. Vamos lá?

Conforme Sommerville (2011, p. 42), um processo de software é conside-rado um conjunto de atividades, que pode levar a construção de um software, e embora existam processos diferentes, algumas atividades fundamentais são comuns a todos, como:

■ Especificação de software: define a funcionalidade do software e as res-trições sobre sua operação devem ser definidas.

■ Projeto e Implementação de software: definem as funcionalidades para que o software atenda à especificação dada pelo cliente.

Introdução ao Projeto, Implementação e Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

■ Validação de software: o software deve ser validado para garantir que faça o que o cliente deseja.

■ Evolução de software: o software deve evoluir para atender as necessida-des mutáveis do cliente.

No nosso livro vamos estudar apenas as atividades que envolvem o projeto, a implementação e o teste de software, momento em que o software é validado.

Após os Requisitos de Software terem sido especificados e modelados, é iniciada a primeira fase, o Projeto, em que é definido como o software será cons-truído, sua arquitetura, interfaces, componentes que poderão ser utilizados e outras características que podem ser determinantes para se gerar um software. Conforme Pressman (2011, p. 206), é na fase de requisitos que é convertido o “que” é para ser feito e detalhado e na fase de projeto é indicado o “como” deverá ser o desenvolvimento, fornecendo detalhes da arquitetura e os componentes essen-ciais para a implementação do sistema. O profissional responsável por essa fase é conhecido como o Arquiteto de Software, que possui experiência como pro-gramador e possui amplos conhecimentos sobre a Gerência de Projetos.

Na segunda etapa, codificamos o sistema conforme o que foi definido na etapa de Projeto. Nesta fase, definimos a linguagem que será usada, ferramentas que poderão auxiliar, bibliotecas de classes para acelerar as tarefas, e ferramen-tas CASE, que podem ser usadas para agilizar a compreensão na hora de gerar os códigos e a documentação do software. O profissional responsável por essa etapa é o Programador ou Desenvolvedor, que precisa ter um bom raciocínio lógico e gostar de resolver problemas.

Depois na terceira etapa, é o momento em que os Testes são executados. Nessa fase, fazemos a validação do comportamento de cada funcionalidade dos módulos do sistema. É nessa fase que verificamos o que foi definido na Análise de Requisitos e rastreamos os possíveis erros e falhas que possam ter ficado em alguma fase. Neste momento, os resultados dos testes executados são mostrados em relatórios, que mostram as informações sobre os erros encontrados e como o software está se comportando até o momento. O profissional responsável por essa fase é o Testador, que pode ser conhecido por outras denominações como: Gerente de Testes, Projetista de Testes, Analista de Testes, entre outros nomes.

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Assim, ao final da etapa de Testes, todos os módulos do sistema são rela-cionados e integrados dando origem ao produto de software, que deve ser mostrado ao usuário para que ele verifique se o sistema desenvolvido atende as suas necessidades.

Na visão de Pressman, as atividades do processo de software:

Para muitos projetos de software, as atividades metodológicas são aplicadas iterativamente conforme o projeto se desenvolve. Ou seja, comunicação, planejamento, modelagem, construção e emprego são aplicados repetidamente quantas forem as iterações do projeto, sendo que cada iteração produzirá um incremento de software. Este disponi-bilizará uma parte dos recursos e funcionalidades do software. A cada incremento, o software torna-se mais e mais completo. (PRESSMAN, 2011, p. 41).

Para Sommerville (2011, p.124) “o Projeto e Implementação de software é um estágio do processo no qual um sistema de software executável é desenvolvido. O Projeto de software é uma atividade criativa em que você identifica os compo-nentes de software e seus relacionamentos com base nos requisitos do cliente. A Implementação é o processo de concretização do projeto como um programa. O Projeto e a Implementação estão intimamente ligados e, ao elaborar um projeto, você deve levar em consideração os problemas de implementação”. E os testes de software? O teste mostra o que um programa faz e o que ele foi proposto a fazer e assim descobrir as falhas que o sistema tem antes do uso do cliente. Isso por-que nessa fase testamos o por-que foi projetado e o por-que foi implementado.

Vamos resumir as fases para que fique mais claro o que veremos nesta disciplina:

■ Projeto: é esclarecido “como” o software será desenvolvido.

■ Implementação: é definida a linguagem que será usada para programar (codificar) o sistema.

■ Teste: o software é testado, levando em consideração o que foi levantado nos requisitos.

Introdução ao Projeto, Implementação e Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Figura 1- Modelo Cascata

Projeto de sistema e software Implementação e teste de unidade Integração e teste de sistema Operação e manutenção Definição de requisitos Fonte: Sommerville, (2011).

Conforme Pressman (2011, p. 207), o Projeto de Software reside no núcleo téc-nico da engenharia de software sendo aplicado independentemente do modelo de processos de software utilizado, iniciando-se assim que os requisitos de sof-tware forem analisados e modelados sendo assim, o projeto é a última ação da engenharia de software da atividade de modelagem e prepara a cena para a fase de implementação (geração de código) e depois para os testes (validação).

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Agora, aluno(a), vamos entender um pouco mais sobre cada fase nesta unidade, e, depois, com mais detalhes nas unidades posteriores do livro. Começaremos conhecendo um pouco mais sobre a fase de Projeto de Software.

O Processo de Software

Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho (work product). Uma atividade esforça-se para atingir um objetivo amplo (por exemplo, comunicação com os interessados) e é utilizada independentemente do campo de aplicação, do tamanho do projeto, da complexidade de esforços ou do grau de rigor com que a en-genharia de software será aplicada. Uma ação envolve um conjunto de ta-refas que resultam num artefato de software fundamental. Uma tarefa se concentra em um objetivo pequeno, porém, bem definido (por exemplo, realizar um teste de unidades) e produz um resultado tangível. No contex-to da engenharia de software, um processo não é uma prescrição rígida de como desenvolver um software. A intenção é a de sempre entregar software dentro do prazo e com qualidade suficiente para satisfazer àqueles que pa-trocinaram sua criação e àqueles que irão utilizá-lo.

Fonte: Pressman (2011).

“Todo engenheiro de software deve reconhecer que modificações são natu-rais. Não tente combatê-las.”

©shutt erst ock Projeto de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

PROJETO DE SOFTWARE

O conceito de Projeto de Software, conforme Pressman, é definido como: A atividade de projeto de software engloba o conjunto de princípios, con-ceitos e práticas que levam ao desenvolvimento de um sistema ou produto com alta qualidade. Os princípios de projeto estabelecem uma filosofia que prevalece sobre as atitudes e ações do desenvolvimento, orientando as atividades para realizar o projeto. Os conceitos de projeto devem ser esta-belecidos e entendidos antes de aplicar a prática de projeto, que deve levar à criação de várias representações do software que servem como um guia para a atividade de construção que se segue. (2011, p. 206).

Por sua vez, Sommerville define Projeto de Software como:

Um projeto de software é a descrição da estrutura de software a ser im-plementada, dos dados que são partes do sistema, das interfaces entre os componentes do sistema, e às vezes dos algoritmos usados. (2011, p. 50). Podemos citar outros conceitos de Projeto. Conforme a ABNT (Norma técnica NBR 10006), projeto é considerado um “Processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empre-endido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos”.

O Projeto de Software faz parte dos processos da Engenharia de software, ele inicia logo após a Análise de Requisitos ter sido levantada, analisada e modelada. O projeto tem como objetivo definir uma estrutura que possa ser implementada em um produto de software e que atenda aos requisitos especificados para ele na análise. Na Análise de Requisitos é levantado “o que” será implementado, no Projeto de Software é definido “como” será construído.

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

O projeto de software é um processo que possui as seguintes atividades: estrutura de dados, arquitetural, componentes e interface. Cada um dos proje-tos citados acima, será detalhado na unidade II do livro.

Conforme Pressman (2011, p. 206), o Projeto de Software cria uma repre-sentação fornecendo detalhes sobre a arquitetura do software, as estruturas de dados, interfaces e componentes fundamentais para implementar um sistema.

Quando pensamos em projeto, devemos sempre ter em mente que quanto mais detalhado e refinado ele for, mas fácil e tranquila será a próxima fase de implementação. Portanto, é importante conhecer todas as tecnologias envolvidas em que o software será implantado e suas soluções, caso ocorram imprevistos. A qualidade do software pode ser avaliada nesta fase, pois o projeto serve de base para as demais fases no desenvolvimento de um sistema.

Conforme Pressman (2011, p.116), os modelos de requisitos representam os requisitos dos clientes. Os modelos de projeto oferecem uma especificação con-creta para a construção do software.

Figura 2 - Transformando o modelo de requisitos no modelo de projeto.

Projeto de dados/classes Projeto arquitetural Projeto de interface Projeto de componentes Modelos de projeto Elementos baseados em cenários

Casos de uso - texto Diagramas de casos de uso Diagramas de atividades Diagramas de Raias

Diagramas de fluxo de dados

Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento Elementos baseados em classes Diagrama de classes Pacotes de análise Modelos CRC Diagramas de colaboração Elementos comportamentais Diagramas de estados Diagramas de sequência Modelos de análise Fonte: Pressman, (2011).

Projeto de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Segundo Pressman (2011, p. 178) o modelo de requisitos é usado para preen-cher a lacuna entre uma representação sistêmica que descreve o sistema (como o usuário imagina) como um todo ou a funcionalidade de negócio, e o modelo de projeto de software é usado para descrever a arquitetura da aplicação de sof-tware, a interface do usuário e a estrutura no nível de componentes.

Figura 3 - A Fase do Projeto

Domínio do problema Domínio da solução Análise e Especificação de Requisitos (o quê) Projeto (como) Mundo Real Mundo Computacional Implementação Fonte: Falbo, (2012).

Seguindo a visão de Pressman sobre a fase de projeto, temos:

O processo de projeto passa de uma visão macro do software para uma visão mais estreita que define os detalhes necessários para implementar um sistema. O processo começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos mecanismos de comunicação entre os subsistemas; são identificados componentes; e é desenvolvida uma descrição detalhada de cada componente. Além disso, são proje-tadas interfaces externas, internas e para o usuário. (PRESSMAN, 2011, p. 226).

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Conforme Falbo (2012), o objetivo da fase de projeto é definir e especificar uma solução a ser implementada para um problema. Assim, podemos dizer que é uma fase em que tomamos muitas decisões, pois temos ao nosso alcance mui-tas soluções que podem ser possíveis. Ainda, segundo Falbo (2012), o projeto é um processo de refinamento.

Assim, de maneira geral, Falbo (2012, p. 10) descreve que um projeto deve: ■ Considerar abordagens alternativas com base nos requisitos do problema. ■ Restrições e conceitos de projeto.

■ Ser rastreável a sua especificação.

■ Não “reinventar a roda”, isto é, reutilizar soluções.

■ Exibir uniformidade (estilo) e integração (interfaces bem definidas entre-componentes da coisa a ser construída).

■ Ser estruturado para acomodar mudanças. ■ Ser passível de avaliação da qualidade. ■ Ser revisado para minimizar erros.

Também, segundo Falbo (2012, p. 10) em geral, um modelo de projeto deve: ■ Prover uma visão da totalidade do que deve ser construído.

■ Decompor o todo em partes e prover diferentes visões.

■ Refinar e descrever com mais detalhes cada parte ou visão do que deve ser construído, de modo a prover orientação para a construção de cada detalhe.

Projeto de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998. Planejamento de projetos

Uma coisa é exigir dos engenheiros de software estimativas de prazos, e cobrar o cumprimento dos prazos prometidos. Clientes e gerentes podem e devem fazê-lo. Outra coisa é pressioná-los para que façam promessas que não podem ser cumpridas. Uma frase comum desta cultura é: “Não me in-teressa como você vai fazer, desde que entregue no prazo!”. Na realidade, o cliente ou gerente deve, no seu próprio interesse, ter algum meio de checar se o cronograma e orçamento propostos são realistas; se preciso, recorren-do aos serviços uma terceira parte. A cultura recorren-do prazo político é ruim para todos. Para os desenvolvedores, ela significa estresse e má qualidade de vida. Para os gerentes, perda de credibilidade e prejuízos. E para os clientes, produtos de má qualidade e mais caros do que deveriam. Ainda por cima, entregues fora do prazo.

Fonte: Paula Filho, (2009).

“Os princípios de projeto estabelecem uma filosofia que prevalece sobre as atitudes e ações do desenvolvimento, orientando as atividades para realizar o projeto.”

©shutterstock Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

IMPLEMENTAÇÃO DE SOFTWARE

Conforme Sommerville (2011, p. 25), a implementação de software é o pro-cesso de conversão de uma especificação do sistema em um sistema executável. A fase de implementação sempre começa quando a fase de projeto tiver sido encerrada. Na Implementação de Software serão detalhados os componentes que foram descritos na fase de projeto, como os códigos-fonte usados na lin-guagem de programação, lembrando que devem ser conforme as tecnologias que foram informadas.

Na implementação é definida a linguagem de programação, que pode ser Java, C#, PHP, C++ ou qualquer outra, que possa desenvolver o que foi mode-lado na fase de projeto. O código é escrito por programadores e é importante que haja uma organização na escrita das instruções. Essa organização pode ser definida com a criação de padrões a serem seguidos pela equipe de programação. Exemplo de padrões que podem ser definidos: declaração de nomes de variáveis, formato de cabeçalhos, comentários dos códigos e como documentar o código. Nessa fase, construímos e codificamos os programas e os módulos que envol-vem o software são integrados.

Pressman (2011, p. 395) afirma que os problemas de confiabilidade de software podem quase sempre ser associados a defeitos de projeto ou de implementação.

Implementação de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Ele afirma que todas as falhas que um software possui estão associadas aos pro-blemas na fase de projeto e de implementação. Segundo o autor, as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o software.

A fase de implementação é uma maneira de formalizar ou mostrar, utili-zando uma linguagem de programação, das análises e os modelos levantados nas fases de requisito e de projeto, e gerando assim um sistema que possa exe-cutar as tarefas que foram descritas pelo usuário. Pressman afirma que podemos definir a implementação como sendo a fase de programação que transformará o projeto em um sistema com forma computacional mais palpável pelo usuário. Na fase de implementação, também podem ser iniciados alguns testes (fase que será vista posteriormente), por exemplo, os testes de depuração de erros que são executados durante a programação e podem ser executados pelos próprios programadores. É importante que nessa fase as “versões” do sistema que estão sendo implementadas sejam controladas e gerenciadas, para que se tenha um controle de tudo o que está sendo codificado e alterado.

Questões importantes na implementação de software

A implementação demanda grande parte do tempo no processo de desen-volvimento de um software, por ser uma das atividades mais trabalhosas e exigir grandes habilidades do profissional da área de informática. Assim, antes de se iniciar a etapa de implementação de um software, é necessário escolher o ambiente de programação e tratar outras questões que possam influenciar direta ou indiretamente no bom desempenho dessa atividade. Além da escolha do ambiente de programação, existem boas práticas a se-rem seguidas para facilitar, principalmente, a manutenção do software e, ainda, alguns problemas a serem solucionados relativos à documentação, às rotinas de teste, à integração da equipe de desenvolvimento e à compo-sição de arquivos de configuração da aplicação. No caso de um ambiente orientado a objetos, outros problemas surgem, como, por exemplo, contro-le de instâncias e relacionamentos entre objetos e persistência de objetos.

©shutterstock Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

TESTE DE SOFTWARE

Segundo Weber et al. (2001), a qualidade de software é determinada pela quali-dade dos processos que são usados durante a fase de desenvolvimento do software. A qualidade de software é o resultado de atividades que foram realizadas no processo de desenvolvimento desse software. Quando se fala em qualidade de software, é necessário lembrar que o projeto do software, o processo de desen-volvimento e o produto final têm que ter qualidade também (REZENDE, 2005). O software tornou-se um componente importante e de sucesso para várias empresas desenvolvedoras, fazendo que haja uma crescente busca pela quali-dade do seu produto final, o software (WEBER et al., 2001). Conforme Pressman (2011), a atividade de teste de software é uma garantia de qualidade de software e ela é a última fase que representa a revisão do que foi especificado nas fases de projeto e implementação.

Conforme Sommerville (2011), os objetivos da fase de teste de software podem ser expressos, de forma mais clara por:

■ Atividade de Teste: processo de executar um programa com a intenção de localizar um defeito/ erro.

■ Caso de teste bom: apre-senta uma elevada probabilidade de revelar um defeito/erro ainda não descoberto.

“Quando seu cliente tiver uma necessidade legítima, mas sem a mínima ideia em relação a detalhes, faça um protótipo para uma primeira etapa.”

Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

O objetivo de qualquer empresa de software é produzir software com qua-lidade, nos prazos estabelecidos e que obtenha a satisfação do cliente. Para isso, devemos produzir o software conforme os requisitos que foram levantados e implementá-los nos prazos estabelecidos e com um nível de defeitos aceitável, para a satisfação do cliente (PRESSMAN, 2011).

Conforme Molinari (2003), o teste é uma atividade que deve ocorrer paralela ao desenvolvimento e conduzida nas diversas fases do processo de desenvol-vimento de software. E, para isso, o teste deve ser planejado, controlado e supervisionado por profissionais experientes. A equipe de teste deve identificar e minimizar os erros no software e executar atividades em paralelo ao teste, como documentação e relatórios. Bastos (2006) aponta que quanto menos defeitos forem deixados no software nas fases iniciais, menos custos terá a sua manuten-ção depois do software estiver pronto.

Sobre o teste, Pressman (2000, p. 78) afirma:

O teste muitas vezes requer mais trabalho de projeto do que qualquer outra ação da engenharia de software. Se for feito casualmente, perde--se tempo, fazemperde--se esforços desnecessários, e, ainda pior, erros pas-sam sem ser detectados. Portanto, é razoável estabelecer uma estratégia sistemática para teste de software.

De acordo com Molinari (2003), todo software que se destina ao público e/ou ao mercado deve sofrer um nível mínimo de teste. Assim, quanto maior o nível de complexidade do software, mais testes e técnicas de testes se tornam neces-sários para a obtenção da sua qualidade.

Sem os testes, não se consegue garantir que o software irá se comportar con-forme o esperado ou concon-forme as solicitações do cliente, e isso pode ser negativo para a empresa que o desenvolveu. Mas caso na empresa não se tenha uma análise de requisitos ou uma documentação do software detalhada, a equipe de desen-volvimento e a equipe de teste não saberão se o que está sendo construído é o que o cliente espera. Pensando nisso, Molinari (2003) destacou axiomas e con-ceitos que podem ser usados no processo de teste, e que em muitos casos são considerados como verdades no mundo dos testes. Podem ser listados como:

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

■ Não é possível testar um programa completamente. ■ Teste de software é um exercício baseado em risco.

■ Teste não mostra que bugs não existem, mas sim, o contrário. ■ Quanto mais bugs são encontrados, mais bugs poderão aparecer. Rios (2008, p.13) denuncia que os testadores querem destruir o software, nocau-teando através da busca de falhas e indicando seus erros, pois conforme o autor, uma vez que se indicam os defeitos de um software, ele pode ser corrigido e com isso, se torna muito melhor.

Conforme Rios e Moreira (2013, p.10), “se não se podem descobrir todos os defeitos de um programa e em decorrência disso nunca se pode afirmar que ele está 100% correto, por que testar? Porque o propósito dos testes é descobrir e corrigir os problemas e, com isso melhorar a sua qualidade. O quanto se quer melhorar dependerá de quanto se deseja investir”. O autor ainda acrescenta, que “na prática, não se pode testar um programa por completo e garantir que ele ficará livre de bugs. É quase impossível testar todas as possibilidades de formas e alternativas de entrada de dados, bem como testar as diversas possibilidades e condições criadas pela lógica do programador” (RIOS; MOREIRA, 2013, p. 10). Conforme Pressman (2011, p. 402), “muitas estratégias de teste de software já foram propostas na literatura. Todas elas fornecem um modelo para o teste e todas têm [...] características genéricas”, e elas são:

■ Executar um teste eficaz, proceder revisões técnicas eficazes.

■ Teste começa no nível de componente e progride em direção à integra-ção do sistema.

■ Diferentes técnicas de teste são apropriadas para diferentes abordagens. ■ O teste é feito pelo desenvolvedor do software e (para grandes projetos)

por um grupo independente de teste.

■ O teste e a depuração são atividades diferentes, mas a depuração deve ser associada com alguma estratégia de teste.

Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Para Pressman (2011), o teste dificilmente chega ao fim. O que acontece é uma transferência do desenvolvedor para o seu cliente, ou seja, toda vez que um cliente usa o sistema, um teste está sendo realizado.

“Os problemas de confiabilidade de software podem quase sempre ser asso-ciados a defeitos de projeto ou de implementação”.

(Pressman).

O testador deve saber exatamente o seu nível de competência que é medi-do pela sua experiência e pelos cursos que fez. Não tente testar um software para o qual você não tenha o conhecimento técnico suficiente. Testar sof-twares embarcados não é a mesma coisa que testar sofsof-twares comerciais. A sua graduação como testador deve sempre dizer até onde você poderá chegar com o seu trabalho, logo não ultrapasse limites, pois nessas faixas é que poderão aparecer os seus maiores defeitos. Aquele testador que regis-tra um defeito dando palpites técnicos sobre como o software deveria ser desenvolvido, com toda a certeza está ultrapassando os seus limites. Conhe-ça a sua área de atuação e os limites que demarcam os seus conhecimentos daqueles inerentes aos do desenvolvedor.

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

CONSIDERAÇÕES FINAIS

Chegamos ao fim da nossa primeira unidade do livro. Nela discorremos sobre as fases que envolvem o processo de desenvolvimento do software e vimos tam-bém os conceitos voltados ao projeto, à implementação e o teste de software.

Foram apresentados aspectos relativos ao projeto, mostrando a importância dela e como essa fase é fundamental para o desenvolvimento de um software. Um dos principais objetivos visto da fase de projeto, e que ela define como vai ser a arquitetura do software, tendo como base o que foi levantado na análise de requisitos.

Ao longo da unidade, foram relacionados os conceitos de implementação, pois é nesta fase que o projeto se transformará em um sistema, em que os códi-gos de programação serão codificados baseados nas definições descritas na fase de projeto. A implementação faz uso de linguagens de programação, podendo ser visuais e orientadas a objeto, do que foi analisado na análise de requisitos e o que foi determinado na fase de projeto.

Vimos os conceitos iniciais sobre qualidade, que está intimamente relacio-nada às atividades de teste. Também verificamos que sem os testes o software pode se comportar de maneira inesperada ou ainda não seguir o foi esperado ou analisado. Isso pode fazer com que o cliente ache que pagou por um produto que ele não solicitou, e tal fato pode ser negativo para a empresa que está desen-volvendo o sistema.

Espero que, até aqui, já tenho colaborado com o seu entendimento do que é projeto, implementação e teste de software, já que estes são os nossos principais assuntos que serão discutidos durante o nosso estudo durante a disciplina. Nas próximas unidades do livro há informações mais detalhadas sobre cada uma das fases. Preparado(a)? Então, vamos continuar com a leitura!

1. Após os Requisitos de Software terem sido especificados e modelados, é iniciada a primeira fase, em que é definido como o software será construído, sua arqui-tetura, interfaces, componentes que poderão ser utilizados e outras característi-cas que podem ser determinante para se gerar um software. Qual o nome desta fase?

2. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F) a assertiva falsa sobre os processos de software.

( ) Projeto e Implementação de software: definem as funcionalidades para que o software atenda à especificação dada pelo cliente.

( ) É nesta fase que são testados os códigos à procura de mais requisitos, que possam causar problemas que podem ocorrer na interface e outros que possam surgir quando o sistema é integrado.

( ) A implementação de software é o processo de conversão de uma especifica-ção do sistema em um sistema executável.

( ) O projeto de software é a última ação da engenharia de software da ativida-de ativida-de moativida-delagem e prepara a cena para a fase ativida-de implementação (geração ativida-de código) e, depois, para os testes (validação).

Assinale a opção com a sequência CORRETA. a. V, F, V, V.

b. F, V, V, F. c. V, V, V, F. d. F, V, F, F.

3. Descreva os conceitos de projeto, implementação e testes de software.

4. A afirmação que diz que: “todas as falhas que um software possui estão associa-das aos problemas na fase de projeto e de implementação” está correta? 5. O objetivo de qualquer empresa de software é produzir software com qualidade,

nos prazos estabelecidos e que obtenha a satisfação do cliente. Estamos falando de: ( ) Projeto. ( ) Implementação. ( ) Programação. ( ) Teste. ( )Requisitos.

6. Assinale a alternativa correta que preenche sequencialmente as lacunas do tex-to.

Na ____________ é esclarecido “como” o software será desenvolvido. Por sua vez, no ____________ é definida a linguagem que será usada para programar (codificar) o sistema. E no _______________ o software é testado, levando em consideração o que foi levantado nos requisitos.

a. Implementação, teste, projeto. b. Teste, implementação, projeto. c. Projeto, teste, implementação. d. Projeto, implementação, teste.

7. Quais os profissionais responsáveis pelas fases: Projeto, Programação e Imple-mentação de Software?

8. Qual das fases do processo de desenvolvimento de software, cria-se uma repre-sentação fornecendo detalhes sobre a arquitetura do software, as estruturas de dados, interfaces e componentes fundamentais para implementar um sistema?

SUPORTE A PADRÕES NO PROJETO DE SOFTWARE Alexandre Dantas, Gustavo Veronese

Alexandre Correa, José Ricardo Xavier, Cláudia Werner 1 – Introdução

Fundamentalmente, o projeto de software envolve uma sistemática de decomposição da solução, a começar pela descrição em mais alto nível dos principais elementos do sistema e, em seguida, criando uma visão mais detalhada de como as características e funções deste sistema deverão estar integradas. Projetar software orientado a objetos é uma tarefa difícil, e projetar software orientado a objetos reutilizável e flexível é ainda mais difícil. Este trabalho apresenta mecanismos de suporte à representação, sugestão e identificação de conhecimentos obtidos a nível de projeto, no ambiente de desenvol-vimento de software

[...]

2 – Representação do Conhecimento de Projeto

Projetistas de sistemas de software vêm, ao longo dos anos, reconhecendo a importân-cia de se representar e explorar o conhecimento obtido durante a construção de siste-mas. Uma das formas consiste no reconhecimento e utilização de boas práticas, idéias e soluções já aplicadas em situações de sucesso e fracasso em projetos de software, como heurísticas de projeto, padrões e anti-padrões.

2.1 – Heurísticas de Projeto

Uma heurística de projeto é uma diretriz resultante de conhecimento e experiência que serve como um conselho para tomada de decisões de projeto, sendo de grande im-portância no sentido de guiar o projetista na elaboração de boas soluções ao longo do desenvolvimento. É importante notar que uma heurística não deve ser vista como uma regra inviolável que deva ser seguida em todas as circunstâncias. Possíveis violações a estas heurísticas devem ser consideradas como avisos ou indicadores de que alguma decisão de projeto pode ter sido tomada incorretamente.

2.2 – Padrões

Podemos pensar em um padrão como a reutilização da essência de uma solução para determinados problemas similares. Sintetizando as definições encontradas na literatura, podemos dizer que um padrão resolve um problema recorrente, em um determinado contexto, fornecendo uma solução que comprovadamente funcione, além de informar os resultados e compromissos da sua aplicação, e subsídios para que seja possível adap-tar esta solução a uma variante do problema. Ao contrário das heurísticas, os padrões disponíveis na literatura estão descritos de forma explícita e organizada. Embora exis-tam várias formas de descrição de um padrão, de modo geral, a descrição de um padrão deve conter as seguintes informações: Nome do padrão, o problema, o

contexto, a solução, as consequências, o uso conhecido e os padrões que são relacio-nados. Segundo Buschmann, quanto maior o número de padrões em um sistema de padrões, maior é a dificuldade de entendê-los e utilizá-los.

[...]

2.3 – Anti-Padrões

Um anti-padrão pode resultar da falta de conhecimento de uma solução mais adequada, ou ainda da aplicação de um padrão (teoricamente, uma boa solução) no contexto in-correto. Os anti-padrões descrevem soluções Inadequadas para um problema que resul-ta em uma situação ruim, ou então descrevem como sair de uma situação ruim e chegar a uma boa solução. A presença de “bons” padrões em um sistema bem sucedido pode não ser suficiente. É preciso mostrar que estes padrões geralmente não ocorrem em sistemas mal sucedidos, e que determinadas construções inadequadas (anti-padrões) encontradas em sistemas mal sucedidos geralmente não estão presentes em sistemas bem sucedidos.

[...]

3 – Suporte a Padrões no Ambiente Odyssey

A partir da representação do conhecimento de projeto através dos conceitos descritos na seção anterior, foi implementado um conjunto de mecanismos em um ambiente de desenvolvimento de software visando apoiar a utilização deste conhecimento durante o projeto de software orientado a objetos. Nesta seção, apresentamos detalhes sobre a implementação e funcionamento destes mecanismos.

Instanciação de Padrões de Projeto

O mecanismo de instanciação de padrões de projeto procura oferecer ao usuário proje-tista uma forma de replicar uma solução com base em um padrão identificado para uma situação adequada ao seu projeto em desenvolvimento. Para isso, o padrão, conforme representado no catálogo, é transportado para o diagrama de classes do projetista. Este transporte é caracterizado pela cópia da estrutura de classes e relacionamentos que cor-respondem ao padrão.

[...]

3.3 – Seleção de padrões arquiteturais

Um dos aspectos críticos de se desenvolver software com ênfase arquitetural é a seleção de um estilo, ou padrão arquitetural [9]. Neste sentido, identificamos a oportunidade de apoiar a seleção de padrões arquiteturais utilizando uma abordagem orientada pela necessidade de se obter determinadas características de qualidade para o software a ser produzido. Estas características são baseadas na norma ISO/IEC 9126-1.

O suporte a padrões do ambiente Odyssey oferece um mecanismo para realização de uma comparação entre os requisitos de qualidade arquiteturais identificados para a aplicação e os obtidos pela utilização de cada padrão catalogado, com a intenção de se chegar a um indicador de padrão que melhor represente uma solução para o atendi-mento aos requisitos esperados.

[...]

3.4 – Deteção de Padrões e Anti-Padrões

O suporte a padrões do ambiente Odyssey fornece um mecanismo de detecção de construções boas, assim como ruins. O principal objetivo desta detecção é fornecer su-porte para a reestruturação de sistemas orientados a objetos legados, e também para a avaliação de sistemas ainda em desenvolvimento. A detecção de construções típicas (padrões) permite que o projeto do sistema seja entendido em um nível maior de abs-tração, além de permitir uma avaliação sobre a utilização destes padrões no projeto.

Análise e Projeto de Sistemas – Como analisar, planejar, desenvolver e implementar sistemas de informação

Lucas Nogueira Padrão Editora: Viena

Sinopse: Para que um software atinja seu objetivo fi nal, são necessárias diversas etapas que são analisadas e discutidas neste livro. A análise e projeto de sistemas consiste em um extremo cuidado e infi nito esmero para chegar a um sistema de qualidade.

O livro Análise e Projeto de Sistemas – Como analisar, planejar, desenvolver e implementar sistemas de informação foi escrito de forma clara e objetiva. Entre os tópicos abordados estão: a análise de sistemas, ciclo de vida, metodologia de desenvolvimento, diagramas, projeto e implementação, análise de requisitos do sistema, tipos de objetos e métodos, herança e polimorfi smo, administração de banco de dados, modelagem de processamento de dados, redes e tecnologias de transmissão, sistemas distribuídos, engenharia de software e seus princípios, metodologias ágeis de desenvolvimento de softwares, testes de software e de validação, gerência de projetos PMBOK, gerência de projetos de TI. No fi nal do livro ainda temos um capítulo com exercícios para treinar os conhecimentos adquiridos.

Apresentação: Processo de Comunicação. Para saber mais sobre Processo de Comunicação, acesse o vídeo produzido pela profa_{. Daniela Karine Ramos. Dicas valiosas sobre comunicação.}

Não perca!

Em: <http://www.youtube.com/watch?v=_C3AmzKpJbQ&feature=player_embedded> Acesso em: 20 de out. 2015.

Material Complementar Apresentação: Como trabalhar com testes de software? Nesse vídeo é dado algumas dicas

do por que escolher a área de teste de software que pode ser uma boa escolha para começar a trabalhar na área de TI, ou mesmo como uma opção para buscar um nova oportunidade do mercado de trabalho, visando crescimento na carreira profissional.

Em: <https://www.youtube.com/watch?v=rL48FS-99ac> Acesso em: 20 de out. 2015.

Apresentação: Atividades básicas ao processo de desenvolvimento de Software. Esse artigo demonstra as principais atividades básicas, comuns aos processos de desenvolvimento de software, seus conceitos relevantes, utilizados em organizações que buscam um padrão de qualidade no desenvolvimento de suas aplicações. Recomendo que tire um tempinho e leia as informações contidas neste link para complementar seus estudos. Acesse o site e leia o artigo na íntegra.

Em: <http://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-software/5413#ixzz3p8FdCqmy>. Acesso em: 17 de maio 2016

2006.

DANTAS, A. R., VERONESE, G.; CORREA, A.; XAVIER, J. R.; WERNER, C. Suporte a Padrões no Projeto de Software. Caderno de Ferramentas do XVI Simpósio Brasileiro de Engenharia de Software. Gramado, 2002.

FALBO, R. de A. Projeto de Sistemas de Software: Notas de aula. Vitória: - Universi-dade Federal do Espírito Santo, 2012

MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São Paulo: Érica, 2003.

PAULA FILHO, W. de P. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: Editora LTC, 2009

PRESSMAN, R. Engenharia de Software. 7. Ed. Porto Alegre: AMGH, 2011.

REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de Janei-ro: Editora Brasport, 2005.

RIOS, E. Caratê Aplicado ao Teste de Software. Niterói: Imagem art Studio, 2008. RIOS, E.; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013 SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011. WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software – Teoria e Prática. São Paulo: Prentice Hall, 2001.

VALENTIM, Lucio Gerônimo; DIAS, M. M.; SANTOS, R. C. S. P. Questões importantes na implementação de software. Revista Tecnológica. v. 17. Maringá: 2008, p. 73-80. Disponível em: <http://periodicos.uem.br /ojs/index .php/ RevTecnol/article/down-load /7985/5161>. Acesso em: 25 mar. 2016.

1. Após o levantamento dos requisitos de software, é iniciada a fase de Projeto de software.

2. Alternativa A - V, F, V, V.

3. Projeto: a fase de Projeto de Software faz parte dos processos da Engenharia de software, tendo início após a Análise de Requisitos ter sido levantada e seu objetivo é definir uma estrutura que possa ser implementada em um produto de software e que atenda os requisitos especificados para ele na análise.

Implementação: na fase de Implementação de Software são detalhados os com-ponentes que foram descritos na fase de projeto, como os códigos fonte que serão usados na linguagem de programação.

Teste: a fase de Teste de Software é uma atividade que deve ocorrer paralela ao desenvolvimento e conduzida nas diversas fases do processo de desenvolvi-mento de software.

4. Os grandes problemas de confiabilidade de software podem quase sempre ser associados a defeitos encontrados na fase de projeto ou de implementação, onde as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o software.

5. Teste.

6. D - Projeto, implementação, teste

7. Projeto: o profissional responsável é conhecido como o Arquiteto de Software, que possui experiência como programador e possui amplos conhecimentos so-bre a Gerência de Projetos.

Implementação: o profissional responsável por esta etapa é o Programador ou Desenvolvedor, com um bom raciocínio lógico, gosta de resolver problemas. Teste: o profissional responsável por esta fase é o Testador, que pode ser conhe-cido por outras variações como: Gerente de Testes, Projetista de Testes, Analista de Testes entre outros nomes.

UNID

ADE

II

PROJETO DE SOFTWARE

Objetivos de Aprendizagem

■ Compreender a importância do projeto de software, mostrando os artefatos que serão criados durante o seu desenvolvimento. ■ Entender a importância do projeto e como ele pode minimizar a

distância entre o sistema e o mundo real.

Plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade: ■ A fase de Projeto de Software

■ Conceitos básicos de Projeto Software ■ Qualidade do Projeto

■ Modelo do Projeto

■ Projeto da Arquitetura do Software ■ Projeto de Componentes

■ Projeto de Interface de usuário

■ Modelos de Análise e Projeto de Interfaces ■ Projeto de Dados

INTRODUÇÃO

Caro(a) aluno(a), na unidade anterior, foi introduzido o objetivo do nosso livro e as etapas que envolvem o processo de software e a forma com que se relacio-nam entre si. Descrevemos as etapas que vamos ver: o Projeto, a implementação e o teste de software.

Nesta unidade, convido você a dar continuidade ao estudo destas etapas que envolvem o processo de software, nos aprofundando mais na etapa de Projeto. Vamos, portanto, conhecer mais a fundo os conceitos que envolvem o Projeto e compreender a sua importância e com isso entender como ele pode minimi-zar a distância entre o sistema e o mundo real.

Você já parou para pensar como é importante a interface de qualquer sis-tema, pois são desenvolvidos para serem manuseados por pessoas? Na fase de Projeto, definimos como vai ser esta interface com o usuário, como serão dis-postos os menus, as janelas, os ícones e todos os componentes que irão fazer parte do sistema a ser desenvolvido e suas funcionalidades. Também fazem parte desta fase, como será o comportamento do sistema, como serão apresentadas as informações de relatórios, comprovantes e tudo que envolve a impressão de informações ao usuário.

Essa fase inicia após ter sido finalizado o levantamento de requisitos de sof-tware junto ao cliente. No Projeto definimos como o sofsof-tware será construído, como será desenvolvida a sua arquitetura, a interface com o usuário, componentes que poderão ser utilizados e outras características que podem ser determinante para se gerar um sistema. Esta fase de Projeto possui como objetivo essencial mostrar e definir uma solução possível a ser implementada com base no que foi levantado na análise de requisitos.

Também nesta unidade, serão apresentados os principais aspectos relati-vos ao Projeto de software, algumas técnicas, modelos e tipos de projetos para que possamos chegar ao final das fases que envolvem um processo de software e com um sistema de qualidade.

Vamos a fase de Projetos! Boa leitura!

Introdução Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

©shutterstock Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

A FASE DE PROJETO DE SOFTWARE

desenvol-vimento de um produto ou sistema. Ele afirma que o Projeto cria um modelo ou uma representação em que é definido o “como fazer”, for-necendo todos os detalhes sobre a arquitetura, a estrutura, a interface e os componentes essenciais para implementar o sistema.

Na fase de Projeto, o principal objetivo é definir uma estrutura que possa ser implementada baseada no que foi descrito nos requisitos que foram levantados para o sistema junto ao cliente. Você saberia disser qual a diferença entre a aná-lise e o Projeto? Na anáaná-lise de requisitos, é modelado o domínio do problema e no Projeto é modelada a solução para o problema, mas ambos devem estar em sintonia, alinhados em um único fluxo, pois o objetivo dos dois é a solução final do problema, neste caso, como software que será desenvolvido.

Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: software, hardware, infraestrutura de rede, a interface de usuário, formulá-rios que devem ser preenchidos e os relatóformulá-rios que o sistema irá fornecer; outros programas específicos que possa vir a usar, quais bancos de dados e arquivos que serão necessários.

Como vimos, na primeira unidade, quem realiza esta etapa é conhecido como o Arquiteto de Software, que possui experiência como programador e pos-sui amplos conhecimentos sobre a Gerência de Projetos. Tal profissional deve compreender e dominar as tecnologias pertinentes, conhecer técnicas de mode-lagem e metodologias de desenvolvimento, entender as estratégias de negócios da instituição onde atua, além de conhecer produtos, processos e estratégias de concorrentes.

A Fase de Projeto de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Pressman (2011) afirma que o projeto é importante, pois ele permite que o sistema seja modelado ou o produto construído. Quando o sistema é mode-lado, ele pode ser avaliado para verificar a qualidade e com isso ser aperfeiçoado antes de passar para a fase de implementação, ou de testes a serem realizado, ou ainda, que os usuários finais apontam os erros. Conforme o autor, o projeto de software pode mudar ao longo de seu desenvolvimento, à medida que novos métodos, uma melhor análise e entendimento do problema ou ainda, surja uma nova solicitação do cliente.

O projeto é considerado o núcleo técnico da Engenharia de Software e, com isso ele pode ser aplicado em qualquer modelo de processo que seja ado-tado pela empresa. Por ser iniciado após a análise de requisitos, o projeto é visto como a última atividade de modelagem, antes da geração do código, ou seja, ele deve ser bem modelado, para que a etapa de construção ocorra sem alterações (PRESMANN, 2011, p. 207).

Na etapa de projeto, deve ser considerado como o sistema funcionará inter-namente, para que os requisitos do cliente possam ser atendidos. Para isso, esta etapa também é dividida em fases, ou melhor, caracterizada por um conjunto de projetos, que ocorrem paralelamente. Conforme Sommerville (2011, p. 110), a fase de projeto deve ter:

■ Projeto da Arquitetura do Software: é a parte em que definimos os com-ponentes estruturais e seus relacionamentos.

■ Projeto de Dados: projeto que tem como objetivo definir a estrutura de dados para implementar o software.

■ Projeto de Interfaces: nesta parte é descrito como será a comunicação den-tro do sistema, com ouden-tros sistemas e com os usuários que iram utiliza-los. ■ Projeto de Componentes: detalhamos os procedimentos dos

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Figura 1 - Modelo Geral do Projeto de Software.

Projeto de arquitetura

Especificação de requisitos

Especificação

abstrata Projeto de interface

Atividades de projeto Produtos de projeto Projeto de componente Projeto de estrutura de dados Projeto de algoritmo Arquitetura

de sistema Especificação de software Especificação de interface

Especificação de estrutura de dados Especificação de algoritmo Especificação de componente Fonte: Sommerville (2011).

Agora, aluno(a) vamos conhecer os importantes conceitos de projeto de software que envolve o desenvolvimento de sistemas. Ótima leitura.

A importância do projeto de software pode ser definida em uma única pa-lavra — qualidade. Projeto é a etapa em que a qualidade é incorporada na engenharia de software. O projeto nos fornece representações de software que podem ser avaliadas em termos de qualidade. Projeto é a única maneira em que podemos traduzir precisamente os requisitos dos interessados em um produto ou sistema de software finalizado. O projeto de software serve como base para todas as atividades de apoio e da engenharia de software que seguem. Sem um projeto, corremos o risco de construir um sistema ins-tável — um sistema que falhará quando forem feitas pequenas alterações; um sistema que talvez seja difícil de ser testado; um sistema cuja qualida-de não poqualida-de ser avaliada até uma fase avançada do processo qualida-de software, quando o tempo está se esgotando e muito dinheiro já foi gasto.

©shutterstock

Conceitos Básicos de Projeto de Software

Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

CONCEITOS BÁSICOS DE PROJETO DE SOFTWARE

Conforme Pressman (2011, p. 212), os principais con-ceitos relacionados ao projeto de software são:

Abstração: o projeto deve considerar uma solução para qualquer problema com vários níveis de abstração, come-çando com um nível de abstração mais alto (solução mais abrangente) e depois para níveis de abstração mais baixos (solução mais detalhada). E que os elementos de projeto sejam representados por suas características essenciais, e os detalhes desnecessários sejam descartados.

Refinamento: processo de elaboração definida em alto nível de abstração e depois vai descendo a níveis de abstração mais baixos. Abstração e refinamento se comple-mentam, pois a abstração especifica os níveis mais altos e mais baixos e o refinamento ajuda a revelar os detalhes menores, conforme o projeto vai evoluindo.

Modularidade: o projeto é dividido em módulos/componentes que são inte-grados para corresponder aos requisitos levantados. Possui algumas vantagens como a facilidade de entendimento, pois cada módulo pode ser estudado sepa-radamente e com isso facilitar o desenvolvimento, uma vez que cada módulo pode ser projetado, implementado e testado separadamente, diminuindo os erros e facilitando a manutenção.

O projeto de software sempre deve começar levando em consideração os dados — a base para todos os demais elementos do projeto.

Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

Padrões: fornece uma descrição ao arquiteto de software permitindo deter-minar qual o padrão a ser aplicado e quais podem ser reutilizados no sistema.

Arquitetura: estrutura ou organização dos módulos/componentes do programa e como eles interagem. O conceito de arquitetura está amplamente ligado aos aspec-tos da estrutura hierárquica dos módulos e as estruturas de dados de um software.

Hierarquia de Controle: é a representação da estrutura do software rela-cionando aos componentes. Aqui o objetivo não é apresentar os detalhes dos procedimentos e sim de estabelecer os relacionamentos entre os componentes de software, seus níveis de abstração e refinamentos.

Encapsulamento: define e impõe restrições de acesso tanto a detalhes pro-cedurais em um módulo quanto em qualquer estrutura de dados local usada pelo módulo. A interface que foi definida deve revelar o mínimo da sua estru-tura interna e com isso reduzir os efeitos colaterais que possam vir a ocorrer.

Estrutura de Dados: representam os relacionamentos lógicos, como estão organizados os métodos de acesso, as associações e as alternativas de processa-mento de informações, pois, à medida que o Projeto vai se aproximando da fase de Implementação, as representações vão se tornando cada vez mais importan-tes, já que as estruturas de dados exercem um grande impacto no projeto final.

Procedimentos de Software: expressam os detalhes da operação de cada módulo/componente do software individualmente. Estes detalhes são: como a informação é processada, pontos de decisão, quais as sequências de evento, e que operações serão repetitivas.

Ocultação de Informação: seu objetivo é propor uma maneira de decom-por o problema, assim, obter módulos menores do software no desenvolvimento. Com isso, o Arquiteto de Software ganha um alto grau de independência entre os módulos, facilitando a sua modificação, quando necessário, e em consequ-ência, a fase de testes.

Conceitos Básicos de Projeto de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.

No próximo tópico vamos conhecer a qualidade do Projeto de software e entender porque a qualidade é tão importante e porque começamos a introdu-zi-la nessa fase. Boa leitura.

Um conjunto de conceitos fundamentais de projeto de software evoluiu ao longo da história da engenharia de software. Embora o grau de interesse em cada conceito tenha variado ao longo dos anos, cada um resistiu ao tempo. Esses conceitos fornecem ao projetista de software uma base a partir de qual métodos de projeto mais sofisticados podem ser aplicados. Ajudam--nos a responder as seguintes questões:

• Quais critérios podem ser usados para particionar o software em compo-nentes individuais?

• Como os detalhes de função ou estrutura de dados são separados de uma representação conceitual do software?

• Quais critérios uniformes definem a qualidade técnica de um projeto de software?

Os conceitos fundamentais de projeto de software fornecem a organização necessária para estruturá-la e para “fazer com que ele funcione corretamen-te”.

Fonte: Pressman (2011).

Existe uma tendência de ir imediatamente até o último detalhe, pulando as etapas de refinamento. Isso induz a erros e omissões e torna o projeto muito mais difícil de ser revisado. Realize o refinamento gradual.