SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO DE GRADUAO EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

ANDRE GALEANO DE OLIVEIRA

TRABALHO INTERDISCIPLINAR
Eixo temtico: Aplicar os conceitos estudados no semestre no cenrio proposto "Nossa Locadora de Livros"

Jaru 2012 1

ANDRE GALEANO DE OLIVEIRA

TRABALHO INTERDISCIPLINAR
Eixo temtico: Aplicar os conceitos estudados no semestre no cenrio proposto "Nossa Locadora de Livros"

Trabalho apresentado ao Curso de graduao em Analise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paran, para as disciplinas de Analise de Sistemas I, Engenharia de Software, Banco de Dados I e Linguagens e Tcnicas de Programao II Professores: Polyanna P. Gomes Fabris, Luis Claudio Perini, Roberto Nishimura e Anderson Macedo. Polo: Jaru - Rondnia.

SUMRIO
Jaru 2012

1. INTRODUO -------------------------------------------------------------------------------- 4 2. DESENVOLVIMENTO ---------------------------------------------------------------------- 5 2.1. O Processo de Inspeo de Software ----------------------------------------------------- 5 2.2. Verificao e Validao do Software ----------------------------------------------------- 7 2.3. Teste de Software ---------------------------------------------------------------------------- 8 2.3.1 Tipos de Teste de Software --------------------------------------------------------------- 8 3. SGBD RECOMENDADO LOCADORA DE LIVROS ------------------------------ 9 4. LINGUAGEM DE PROGRAMAO RECOMENDADA --------------------------- 9 4.1. Facilidade de uso ---------------------------------------------------------------------------- 9 5. MODELO DE PROCESSO ----------------------------------------------------------------- 10 6. CONCLUSO -------------------------------------------------------------------------------- 11 7. REFERNCIAS BIBLIOGRFICAS ----------------------------------------------------- 12

1. INTRODUO

A utilizao de softwares hoje j cotidiano na vida de todos, em qualquer casa ou empresa, etc,. Qualquer usurio de um computador qualquer, j teve contato com softwares, direta ou indiretamente. A cada dia, se desenvolvem mais e mais programas, seja para utilizao empresarial ou caseira. O fato que esse mercado cresceu e tende a crescer mais e mais com a modernizao e popularizao da informatica. Consequentemente, as empresas que fabricam esses softwares, gastam boa parte do tempo e do processo de fabricao do produto no gerenciamento de qualidade do mesmo. Falaremos neste trabalho sobre o processo de fabricao de softwares, dando nfase na qualidade desse processo, os testes a serem feitos, para que o produto final tenha o efeito desejado e as metas alcanadas.

2. DESENVOLVIMENTO

2.1. O Processo de Inspeo de Software Segundo a revista Engenharia de Software, na engenharia de software, assim como em outras disciplinas de engenharia, necessrio considerar variveis como esforo, produtividade, tempo e custo de desenvolvimento. Essas variveis so afetadas negativamente quando artefatos defeituosos so produzidos, devido ao retrabalho para corrigir defeitos. Sabe-se, ainda, que o custo do retrabalho para correo de defeitos aumenta na medida em que o processo de desenvolvimento progride. Desta forma, iniciativas devem ser realizadas no sentido de encontrar e corrigir defeitos to logo sejam introduzidos. Uma abordagem que tem se mostrado eficiente e de baixo custo para encontrar defeitos, reduzindo o retrabalho e melhorando a qualidade dos produtos a reviso dos artefatos produzidos ao longo do processo de desenvolvimento de software. Inspeo de software um tipo particular de reviso que pode ser aplicado a todos os artefatos de software e possui um processo de deteco de defeitos rigoroso e bem definido. A Figura 1 ilustra a possibilidade de se realizar inspees nos diferentes artefatos de software. De forma resumida, o processo tradicional de inspeo envolve o planejamento da inspeo, indivduos revisando um determinado artefato, um encontro em equipe para discutir e registrar os defeitos, a passagem dos defeitos para o autor do artefato para que possam ser corrigidos e uma avaliao final sobre a necessidade de uma nova inspeo.

Figura 1. Inspees

de

Software

nos

Diferentes

Artefatos. Adaptado

de

(ACKERMAN et al., 1989) A importncia de inspees na reduo do retrabalho e na garantia da qualidade de software est bem documentada na literatura e discutida em maiores neste artigo. A seo seguinte apresenta a definio de alguns conceitos utilizados ao longo deste 5

trabalho. Veremos ainda neste artigo alguns benefcios de se realizar inspees em artefatos produzidos ao longo do processo de desenvolvimento de software so descritos; conceitos sobre tcnicas de leitura para deteco de defeitos em artefatos de software; o processo de inspeo de software e suas caractersticas, e; o estado atual da utilizao de inspees na prtica e do suporte ferramental existente. Definio dos Conceitos O termo defeito muitas vezes utilizado de forma genrica. No entanto, importante ter em mente que sua interpretao depender do contexto em que ele for utilizado. Defeitos encontrados atravs de revises estaro relacionados s faltas no artefato sendo revisado. Quando um defeito se manifesta atravs de atividades de teste, por sua vez, estaremos lidando com uma falha no software. Estas definies seguem a terminologia padro para Engenharia de Software do IEEE (IEEE 610.12, 1990): Erro: um defeito cometido por um indivduo ao tentar entender uma determinada informao, resolver um problema ou utilizar um mtodo ou uma ferramenta. Defeito (ou Falta): uma manifestao concreta de um erro num artefato de Falha: o comportamento operacional do software diferente do esperado pelo software. Um erro pode resultar em diversos defeitos. usurio. Uma falha pode ter sido causada por diversas faltas e algumas faltas podem nunca causar uma falha. Em alguns momentos o termo discrepncia ser utilizado. Este termo refere-se a um suposto defeito encontrado. No nosso contexto, uma discrepncia poder ser considerada um defeito de fato ou um chamado falso positivo. Para obter uma classificao para os defeitos encontrados nas revises (as faltas), partimos do fato de que todos os artefatos gerados durante o desenvolvimento de software utilizam como base o documento de requisitos ou artefatos gerados a partir deste. Desta forma, as classes de defeito seriam os tipos de defeito presentes em documentos de requisitos acrescidos dos tipos de defeitos introduzidos pela transformao de artefatos ao longo do desenvolvimento de software. Um padro IEEE (IEEE 830, 1998), que recomenda prticas para especificao de requisitos de software, define atributos de qualidade que um documento de requisitos deve possuir. Foi considerado que a falta de qualquer um destes atributos constituiria um tipo de defeito. Assim, a seguinte taxonomia foi definida: 6

Omisso: (1) Algum requisito importante relacionado funcionalidade, ao

desempenho, s restries de projeto, ao atributo, ou interface externa no foi includo; (2) no est definida a resposta do software para todas as possveis situaes de entrada de dados; (3) faltam sees na especificao de requisitos; (4) faltam referncias de figuras, tabelas, e diagramas; (5) falta definio de termos e unidades de medidas. Ambigidade: Um requisito tem vrias interpretaes devido a diferentes termos utilizados para uma mesma caracterstica ou vrios significados de um termo para um contexto em particular. Inconsistncia: Dois ou mais requisitos so conflitantes. Fato Incorreto: Um requisito descreve um fato que no verdadeiro, Informao Estranha: As informaes fornecidas no requisito no so Outros: Outros defeitos como a incluso de um requisito numa seo errada do

considerando as condies solicitas para o sistema. necessrias ou mesmo usadas. documento.

2.2. Verificao e Validao do Software

um processo que engloba todo o ciclo de vida. o momento em que o desenvolvedor deve fazer certas perguntas a si mesmo ou ao grupo que desenvolve o produdo. Com relao verificao deve se perguntar se estamos construindo o produto de maneira correta. J com relao validao, deve se perguntar se estamos trabalhando no produto correto, investindo no plano certo, se esse mesmo o objetivo que queremos. - Verificao e Validao ( V & V ) deve ser aplicado em cada estgio no processo de desenvolvimento. Tem dois objetivos principais: a descoberta de defeitos no sistema Assegurar se o sistema ou no utilizvel em uma situao operacional. 7

2.3. Teste de Software A testabilidade do software se resume preocupao dos desenvolvedores com relao ao comportamento do produto. Como ele se portou na sua execuo. nesse momento que aparecem ou no, os erros de execuo, falhas na inicializao, morosidade, etc. Um teste bem sucedido um teste que descobre um ou mais erros. a nica tcnica de validao para requisitos no funcionais (desempenho, confiabilidade), deve ser usado em conjunto com a verificao esttica para uma cobertura total das atividades de V&V. 2.3.1 Tipos de Teste de Software A) Os testes de defeito Testes projetados para descobrir defeitos no sistema. Um teste bem sucedido aquele que revela a presena de defeitos em um sistema. B) Testes estatsticos Usado para testar o desempenho e a confiabilidade do programa. Confiabilidade: nmero de falhas no sistema, etc Desempenho Tempo de execuo, tempo de resposta, etc.

3. SGBD RECOMENDADO LOCADORA DE LIVROS Baseado nas informaes, o conselho mais adequado ao gerente da Locadora de Livros implementar na soluo de informatizao seria usar o SGBD PostgreSQL. 8

O PostgreSQL o Sistema Gerenciador de Banco de Dados (SGBD) de cdigo aberto que possibilitou o desenvolvimento de solues corporativas com uma melhor relao custo-benefcio. Um ponto forte desse Sistema a sua capacidade de tratar grandes volumes de dados com alta performance e a sua arquitetura pode ser continuamente ampliada de acordo com a demanda dos usurios. Em estudos realizados em universidades e centros de pesquisa, o PostgreSQL tem apresentado performance, no mnimo 20% superior aos SGBDs comerciais mais conhecidos. 4. LINGUAGEM DE PROGRAMAO RECOMENDADA Foi sugerido ao proprietrio da empresa a utilizao da linguagem DELPHI, por ser uma linguagem voltada ao desenvolvimento comercial de alto desempenho e de fcil utilizao por parte dos desenvolvedores, pois foi criada seguindo o conceito RAD e seu ambiente de desenvolvimento IDE (Integrated Development Environment Ambiente de Desenvolvimento Integrado). Nesse ambiente a forma de construo, da interface dos programas, segue o padro de janelas com todas as facilidades que elas possuem. Assim durante todo o desenvolvimento o programador visualiza o formato de sua aplicao, podendo arrastar e soltar componentes que iro compor sua interface. 4.1. Facilidade de uso Fornece os mecanismos mais convenientes para permitir que as aplicaes acessem bancos de dados (Fields Editor, Mestre/Detalhe, Controle de Navegao - que permite consulta e atualizao-Data Modules); compila uma aplicao inteira gerando um nico arquivo executvel; tem boas facilidades para armazenar objetos customizados e disponibiliz-los para as aplicaes; o tratamento de eventos a nvel de registro mais difcil do que nos outros produtos; oferece dois geradores de relatrio, um que no est bem integrado com a ferramenta (ReportSmith) e outro muito bem integrado, mas difcil de usar. Permite sincronizar datasets mestre e detalhe sem programao adicional; permite incluir, excluir e alterar registros sem qualquer programao adicional; possui o suporte para automao remota mais completo; tem o depurador mais robusto (mostra a pilha de chamadas a procedimentos e funes, caracterstica necessria quando se faz 9

grande reuso de cdigo); oferece mais opes de instalao; no executa um evento cada vez que o usurio se movimenta para um novo registro na tela. 5. MODELO DE PROCESSO Com base no estudo de caso, o Modelo de Processo proposto para o desenvolvimento do sistema foi o Modelo Espiral, pois nesse modelo so executados o planejamento, anlise de risco, engenharia, construo e release, avaliao do cliente e comunicao com o cliente.

6. CONCLUSO Baseado no contedo abordado e discorrido, vemos que por mais simples que seja um produto, o projeto deve ser bem pensado, bem destrinchado por aqueles que so 10

responsveis por faz-lo. Todas as funes devem ser bem projetadas, depois revisadas e corrigidos os erros, caso necessrio. E importante ressaltar, que como a demanda e quantidade de produtos sendo lanados no mercado todos os dias, os erros, por conseguinte, so muito comuns ainda. Talvez pela vontade de "lucrar" logo com o produto, algumas partes do processo, bem como o controle de qualidade, verificao e validao do sistema, so deixadas de lado. E quem sofre com isso o cliente.

7. REFERNCIAS BIBLIOGRFICAS

11

PERINI, Luis Claudio; HISATOMI, Marco Ikuro; BERTO, Wagner Luiz. Engenharia de Software, Pearson Education do Brasil, 2012. Site: http://www.batebyte.pr.gov.br Site: http://www.devmedia.com.br

12