SISTEMA DE ENSINO PRESENCIAL CONECTADO ANALISE E DESENVOLVIMENTO DE SISTEMAS

PRODUO TEXTUAL INTERDISCIPLINAR - EM GRUPO:

Arapiraca 2012

PRODUO TEXTUAL INTERDISCIPLINAR- EM GRUPO:

Trabalho Interdisciplinar ( Educao a Distancia,Anlise de Sistemas I,Engenharia de Software,Banco de Dados I e Linguagens e Tcnicas de Programao II apresentado Universidade Norte do Paran UNOPAR. Professores: Polyanna P. Gomes Fabris Luiz Cludio Perine Roberto Nishimura Anderson Macedo

Arapiraca 2012

SUMRIO 1 INTRODUO...........................................................................................................3 2 DESENVOLVIMENTO...............................................................................................4 3 REQUISITOS.............................................................................................................9

1 INTRODUO O utilizao do software j jaz parte do cotidiano de praticamente todas as pessoas. Mesmo aqueles que pensam que nunca utilizaram um software, internet ou at mesmo um computador, j se beneficiam com os avanos da informtica e tambm podero sofrer as consequncias de um erro ou falha de um software. Atualmente, as empresas desenvolvedoras de software atuam fortemente na qualidade de seus produtos que um dos principais objetivos da engenharia de software. Ento qualidade de software um processo sistemtico que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade do processo e dos produtos prevenindo e eliminando os defeitos. (BARTI, 2002). Na atualidade em que vivemos para que uma empresa desenvolvedora de software sobreviva, necessrio que seus produtos ofeream qualidade e segurana e estejam sempre se inovando e trazendo sempre vantagens X facilidade, para o mercado consumidor que a cada dia se torna mais exigente. De uma coisa ns temos certeza que a cada dia com o avano da tecnologia, novos produtos de software sero criados, para nos oferecer mais segurana e mais comodidade e at mesmo novas possibilidades para o futuro da sociedade.

2 DESENVOLVIMENTO 1.1 OBJETIVO O intuito desse trabalho fazer um levantamento de informaes junto a grandes organizaes de contruo de software e observar os procedimentos usados no dia-a-dia para a qualidade no desenvolvimento de todos os artefatos de software, feito o levantamento de todos os parametros iremos construir a elaborao de um plano de desenvolvimento com enfase na qualidade, ou seja, uma gama de conceitos e praticas da engenharia de software que atuam decisivamente na produo de software de qualidade. Utilizaremos a ferramenta astah para a montagem do diagrama de caso de uso do sistema da biblioteca; o Br modelo nos ajudar na criao de banco de dados conceitual e lgico desse sistema, bem como a linguagem c# nos permitira a criao de telas. Temos como objetivo maior, tentar mostrar a todos um pouquinho do conhecimento adquirido atraves de todo o conteudo que foi estudado no semestre corrente, mostrar uma viso mais ampla de todo o processo de criao e validao de um software.

2.1 PLANO DE DESENVOLVIMENTO PARA DEFINIR A QUALIDADE DO PRODUTO A qualidade deve ser uma caracterstica fundamental de qualquer produto existente. Porem, desenvolver software de qualidade assegurada, dentro do prazo estabelecido e sem necessitar de mais recursos os alocados tem sido um grande desafio para a engenharia de software. A seguir, esto relacionados os principais tpicos tericos e prticos, que quando implementados garantem que o produto final atinja a excelncia no desenvolvimento, ou seja , a nossa viso de proposta ideal na construo de software de qualidade . 2.2 ENGENHARIA DE REQUISITOS Os requisitos do sistema destinam-se a comunicar as funes que o sistema deve fornecer. Invista tempo e tenha pacincia nesta fase to importante de qualquer projeto de software. E preciso entender e documentar de maneira clara e no ambgua os requisitos de determinado problema, s assim, entenderemos de que forma precisa o que deseja o cliente. Isto posto, poderemos a comeara projetar e construir o sistema. Etapas do processo de engenharia de requisitos: concepo, levantamento, elaborao, negociao, especificao e validao. 2.3 MODELOS DE PROCESSO DE SOFTWARE E essencial, antes do desenvolvimento de um produto, preparar um plano geral, ou seja, escolher um modelo de ciclo de vida. Este pode ser personalizado, se adaptando ao tamanho, complexidade e/ou nvel de confiabilidade /segurana do projeto , ou seja, um modelo para um processo de desenvolvimento uma proposta terica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem.? A escolha de um modelo envolve diversos fatores: se um software de banco de dados, um software de tempo real, um software embutido, um sistema especialista. Outros fatores importantes so: se a equipe de desenvolvimento uma empresa de desenvolvimento de software ( software house), uma fabrica de software

(desenvolvimento em linha de produo), ou se

a equipe de engenheiros da

prpria empresa que utilizara o produto. A maneira como o produto ser vendido e instalado tambm tem relevncia: se o software para ser vendido para um publico amplo (software genrico ) ou se ser instalado em uma nica empresa, sob encomenda. So alguns exemplos de modelos: Prototipao, Espiral, Cascata, Extreme Programming, SCRUM, RUP. 2.4 GERENCIAMENTO DE PROJETO Software por natureza um produto intangvel. A gerencia, efetiva de projetos de softwares a garantia de que seu produto ser entregue no prazo, dentro do custo e com os requisitos atendidos. Projeto um processo nico, consistido de um grupo de atividades controladas e coordenada num determinado perodo. So algumas atividades do gerente de projetos: elaborao da proposta , planejamento e desenvolvimento do cronograma do projeto, custo do projeto, monitoramento e revises do projeto, seleo e avaliao do pessoal e elaborao de relatrios e apresentaes. O gerente tambm precisa planejar minuciosamente o progresso do projeto, prevendo e dando solues experimentais para esses problemas. O cronograma uma das tarefas mais difceis de serem executadas, pois os gerentes precisam estimar o tempo e os recursos para conclurem as atividades, organizando as em uma sequencia coerente. A analise de riscos tambm deve fazer parte da rotina do gerente de projetos. A seguir algumas metodologias de gerencia de projetos para auxiliar os profissionais: PDGA , PMBOX e SCRUM. 2.5 ORGANIZAO DO CONHECIMENTO Todos os problemas encontrados e solucionados, deve se transformar em conhecimento adquirido. Este conhecimento, dever ser guardado e organizado para ser usado de maneira rpida e fcil quando for necessrio. Para isso , devemos nos preocupar com questes de treinamento e qualificao do pessoal, a disseminao do conhecimento dentro das organizaes, novos projetos que tenham sua atividades facilitadas com o reuso de software, histricos de tarefas, estatstica de erros e analise de indicadores. Ter acesso a esses dados uma vantagem estratgica significativa para um gerente de projetos nas tomadas de

decises, poder ter sempre informaes concretas e precisas um fator importantssimo no s para um gerente de projetos e sim para qualquer lder de uma organizao. 2.6 MTRICAS PARA MEDIO DE QUALIDADE DO SOFTWARE Medimos a qualidade de determinado processo ou produto, precisamos fazer uso de mtricas de aferio, ou seja, meios para detectar reas de problemas ( internos ), de forma que sejam definidas solues para que o processo seja melhorado de uma forma bem gradativa. Essas medidas so coletadas pelos engenheiros de software e repassadas aos gerentes de projeto de software, que fazem as analises e as avaliaes dos projetos. Mtricas eliminam julgamentos subjetivos sobre o produto e do a organizao uma viso estratgica efetiva de seu processo de software. A medio algo comum no mundo da engenharia. A engenharia de software est longe de ter uma medio padro amplamente aceita e com resultados sem nenhum fator subjetivo. Temos dificuldade em concordar sobre o que medir e como avaliar o resultado das medies obtidas. Mtricas de softwares nos possibilitam realizar uma das atividades mais fundamentais do processo de gerenciamento de projetos que o planejamento. A partir deste, passamos a identificar a quantidade de esforo, o custo e as atividades que sero necessrias para a realizao do projeto. As mtricas de software, do ponto de vista de medio, podem ser divididas em duas categorias: medidas diretas e indiretas. Podemos considerar como medidas diretas do processo de engenharia de software o custo e o esforo aplicados no desenvolvimento e manuteno do software e do produto, a quantidade de linhas de cdigo produzidas e o total de defeitos registrados durante um determinado perodo de tempo. Porm, a qualidade e a funcionalidade do software ou a sua capacidade de manuteno so mais difceis de serem avaliadas e s podem ser medidas de forma indireta. Como podemos observar so vrios os tipos de mtricas e processos para se construir um software com qualidade s basta querer.

2.7 QUALIDADE DE SOFTWARE O gerenciamento de qualidade de software assegura que o mesmo tenha poucos defeitos e que atinja os padres necessrios de funcionamento, facilidade de manuteno, confiabilidade, portabilidade, usabilidade e eficincia. O engenheiro de software deve documentar um conjunto de procedimentos de garantia de qualidade em seu manual de qualidade da organizao. Diante dessa complexidade na definio da palavra qualidade, Pressman (2005) sugere que a qualidade de software seja implementada e no uma ideia ou desejo que uma organizao venha a ter, para tanto, Pressman ( 2005) faz as seguintes colocaes sobre qualidade de software. a) Definir explicitamente o termo qualidade de software, quando o mesmo dito; (PRESSMAN, 2005, p. 193). b) Criar um conjunto de atividades que iro ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade; ( PRESSMAN, 2005, P. 193). c) Realizar atividades de segurana da qualidade em cada projeto de software; (PRESSMAN, 2005, p. 193). d) Usar mtricas para desenvolver estratgias para a melhoria de processo de software e, como consequncia, a qualidade no produto final ; (PRESSMAN, 2005, P. 193). Sendo assim, a busca constante pela qualidade no se faz apenas no comeo do projeto ou no seu final realizando testes, mas sim em um processo que visa abranger toda a engenharia de software bem como a colaborao de todos os membros do time do projeto.

3 REQUISITOS

Os requisitos expressam as caractersticas e restries do produto de software do ponto de vista de satisfao das necessidades do usurio, e, em geral independem da tecnologia empregada na construo da soluo sendo a parte mais crtica e propensa erros no desenvolvimento de software. So objetivos ou restries estabelecidas por clientes e usurios do sistema que a definem as diversas propriedades da soluo. Os requisitos de software so, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software tradicionalmente, os requisitos de software so separados em requisitos funcionais e no funcionais. a) Funcionais: so a descrio das diversas funes que clientes e usurios querem ou precisam que o software faa. Eles de finem a funcionalidade desejada do software. A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a preocupao de como ele faz. b) No funcionais: so as qualidades globais de um software, como manuteno, usabilidade, desempenho, custos e varias outras coisas, normalmente estes requisitos so descritos de maneira informal, descrevem as restries de tempo, do processo de desenvolvimento, padres e ctc. Geralmente, so mais crticos do que os funcionais e se ignorados, podem transformar todo o sistema em algo intil. 3.1 REQUISITOS FUNCIONAIS DO SISTEMA BIBLIOTECA a) O sistema deve manter um cadastro de clientes; b) O sistema deve prover e controlar a renovao do emprstimo de forma on-line; c) O sistema deve manter um cadastro de livros; d) O sistema deve controlar e disparar avisos sobre prazos de devoluo se esgotando a seus clientes;

10

e) e) O sistema deve controlar o nmero mximo permitido de livros emprestados por vez para cada cliente; 3.2 REQUISITOS NO FUNCIONAIS DO SISTEMA BIBLIOTECA a) O cadastro de clientes deve ser simplificado com: nome, endereo, telefone, email e senha; b) O sistema deve vetar emprstimos em caso de atraso confirmado e avisar ao cliente que comparea biblioteca para sanar as pendncias do referido emprstimo; c) O sistema deve limitar, para no mximo 3 (trs) exemplares, os emprstimos por vez para cada cliente; d) O sistema dever comunicar ao cliente, via email, quando faltar1 (um) dia para se esgotar o prazo de devoluo do emprstimo; e) O cadastro de livros deve contemplar de forma obrigatria a localizao e a quantidade de exemplares por titulo.

3.3 DIAGRAMA DE CASO DE USO O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que ser projetado. Cenrio: O cliente chega biblioteca e solicita o emprstimo. O funcionrio verifica no sistema podendo cadastrar o cliente ou efetuar o emprstimo. O cliente de forma on-line, poder efetuar a renovao do emprstimo segundo as regras impostas pelo sistema, bem como gerenciar suas pendncias de emprstimos. O funcionrio tambm pode efetuar renovaes e gerenciar pendncias. O funcionrio mantm o cadastro dos livros informando sempre a localizao e o nmero de exemplares por ttulos. Atores: Cliente e funcionrio. Casos de uso: manter cadastro de cliente; manter cadastro de livro; controlar emprstimos; cadastrar localizao do livro; cadastrar quantidade de volumes por titulo; gerenciar pendencias de emprstimos.

11

Figura 1 . 3.4 PROJETO DE BANCO DE DADOS Aps levantamento dos requisitos, e com a estrutura definida, passaremos agora para a modelagem do nosso banco de dados. Para entender melhor o funcionamento de um banco de dados, importante saber que o computador possui trs tarefas bsicas. So elas: entrada, processamento e sada. A entrada dos dados est relacionada diretamente com a interao do usurio, que na maioria das vezes o responsvel pela insero da informao por meio de teclado, mouse, entre outros dispositivos de entrada. Com relao a sada, os dados que foram informados na entrada passam pelo processamento atendendo a expectativa do usurio e so apresentados por um dispositivo de sada, como por

12

exemplo um monitor ou impressora. No caso do processamento podemos definir simplesmente como interao dos dados de entrada com a sada "De forma simplificada pode-se conceituar banco de dados como sendo um sistema de armazenamento de dados baseado em computador, cujo objetivo registrar e manter informaes consideradas significativas a qualquer organizao ou um nico usurio (DATE, 1990). 3.5 MODELO CONCEITUAL DE BANCO DE DADOS Aps uma breve descrio do funcionamento do banco de dados, daremos prosseguimento a nossa modelagem de entidades e relacionamentos onde a finalidade estruturar a soluo descrevendo de maneira conceitual os dados que sero utilizados em nosso sistema. Para o nosso modelo conceitual foram verificadas a necessidade de trs tabelas ( usurio, locao, livro e gnero )

Figura 2

13

3.6 MODELO LGICO DE DADOS Na modelagem lgica vamos dar incio s regras que cada campo deve conter, onde definiremos as principais caractersticas, informando se o preenchimento obrigatrio ou nulo, numrico, alfanumrico, boleano, etc.Nesse modelo, podemos compreender melhor a relao entre as tabelas USUARIO, CADLIVRO E EMPLIVRO. A relao CADASTRO e a relao EMPRESTIMO, recebem duas chaves identificadoras, cod_usuario da tabela USUARIO e cod_livro da tabela CADLIVRO. Estas relaes que definem as aes dos usurios atravs docod_usuario, qual Estas relaes que definem as aes dos usurios atravs docod_usuario, qual caminho tomar, se para o cadastro ou somente para o emprstimo.

Figura 3

14

4. PROTOTIPO DAS TELAS Passamos agora para o nosso modelo de site que ir interagir com o nosso banco de dados. Nessa fase nos preocupamos principalmente em apresentar grfico so requisitante do software para fazer-se compreender a funcionalidade do sistema. Na pagina de autenticao o usurio ( figura 6) que j cadastrado vai inserir suas credenciais, e o sistema verificar seu tipo de privilgio atravs do cod_usua.

Figura 4 No caso do usurio com privilgios de um administrador, este ser redirecionado para a pgina de cadastro de livros (figura 4), onde ter outros links para interagir com o cadastro de novos usurios alm de controlar emprstimos. A tela CADASTRAR LIVROS ser apresentada assim que o usurio-administrador informar seu login e senha. Os campos para o cadastro do livro que jforam explicados na modelagem conceitual e lgica so obrigatrios e quando efetuado o cadastro de um livro a pagina continua a mesma dando oportunidade para um novo cadastro.

15

Figura 5 e 6, Pgina de cadastro de livros.

No link Cadastrar Usurio, o administrador redirecionado para uma nova tela onde conter novos campos para cadastros de um novo usurio.

16

6 - Concluso Este portflio aborda assuntos da rea de Engenharia de Software, Banco de Dados e Diagramas. Ele nos proporcionou uma maior abordagem da rea de TI.

17

Referncias www.google.com http://www.unopar.br/bibliotecadigital/

18

19

20

21

22