[Seminário] Projeto Astah

Leandro C. de Almeida    RA: 0808186686

Anderson R. Paulblo       RA: 0901381748

¨A ferramenta Jude Community é uma boa ferramenta de modelagem UML gratuita. Por ser uma versão Community possui algumas limitações. Há uma versão Professional disponível, mas os recursos presentes na versão Community podem suprir a necessidade de grande parte dos artefatos necessários no dia-a-dia.

¨Em 2010, a ferramenta foi descontinuada, e a Change Vision, empresa responsável pelo Jude, passou a recomendar a utilização da ferramenta que substituirá o Jude, ferramenta esta batizada de Astah. Assim como o Jude, esta ferramenta possui versões Community e Professional. Dentre os recursos da ferramenta estão:

¨Suporte a UML 2.1

¨Diagramas de Classe, Caso de Uso, Sequência, Atividade, Comunicação, Máquina de Estado, Componentes, Implantação, Estrutura de Composição, Objetos e Pacotes.

¨Ajustes de alinhamento e tamanho dos diagramas

¨Impressão dos diagramas (com a marca d’água da ferramenta)

¨Exportação das imagens dos diagramas (com a marca d’água da ferramenta)

Modelagem de sistema utilizando o Astah* Professional 

  ¨Os sistemas de informação modernos têm ficado cada vez mais complexos e sua construção demanda um esforço de diversas pessoas, representando um contraste com os sistemas desenvolvidos em décadas anteriores onde um único programador usando seus próprios métodos criava e realizava manutenção em seus sistemas. ¨Colocar um grupo de pessoas trabalhando de forma concentrada para chegar a um produto de software não é uma tarefa fácil. Uma das maneiras de enfrentar as dificuldades intrínsecas ao desenvolvimento de um sistema é a adoção de uma forma de trabalho padronizada, uma metodologia. Uma metodologia é um conjunto organizado de métodos e ferramentas que tem por objetivo disciplinar o processo de desenvolvimento de sistemas. ¨Nesse contexto se insere o Astah*, com o seu conjunto de diagramas que visa auxiliar o processo de modelagem de um sistema. O Astah* possui um total de 14 diagramas que, de acordo com a necessidade e complexidade do projeto, podem ser combinados 

  

 

  

 

 

[Seminário] Introdução ao Mantis

Introdução ao Mantis

Edward Furumoto..............................................................RA: 0901413362

Mayara Claro Grego..........................................................RA: 0919436192

A manutenção de software

A manutenção de software é a fase a qual ocorrem modificações no código e em qualquer outro artefato de uma aplicação de software. A manutenção é executada para corrigir falhas na codificação, melhorar o desempenho do software, ou adequá-los aos novos requisitos.

A manutenção representa cerca de 80% do orçamento do orçamento total do ciclo de vida de um software, ou seja, é uma atividade de grande importância de qualquer software.

Dessa manutenção, 20% dos projetos de manutenção são de correção de erros, e a grande maioria é para acrescentar novas funcionalidades ou adaptá-lo a mudanças externas.

Um dos grandes problemas na manutenção de software é a alta rotatividade da equipe de desenvolvimento ou várias gerações subseqüentes de profissionais que modificaram a aplicação e não fazem mais parte da equipe. Assim, sendo necessário desenvolver mecanismos para avaliar, controlar, registrar e rastrear modificações.

Problemas técnicos e gerenciais:

- Complexidade do domínio do problema;

- Obstáculos para gerenciar e estabelecer um processo de desenvolvimento e manutenção;

- Tecnologias ultrapassadas.

Durante a fase de manutenção é possível entrar documentações mal elaboradas, ou nenhuma documentação. Com isso, os desenvolvedores gastam mais tempo analisando o software antes de modificá-los, prejudicando a entrega das demandas de modificações no mesmo.

Entre esses problemas, existem outros, como por exemplo, a maioria dos profissionais é formada com uma visão essencialmente focada no desenvolvimento de novas aplicações. E, não em modelos de manutenção.

Diante disso, a manutenção de software deve ser tratada como uma disciplina, tendo conhecimento nas áreas de manutenção de software como: a configuração de software, engenharia reversa, redocumentação e modelos de gestão para controle de mudanças.

Ciclo de vida de um defeito genérico.

Gerencia de Configuração de Software

Configuração de um sistema de software é uma coleção de versões específicas de itens de configuração que são combinados de acordo com procedimentos específicos de construção para servir a uma finalidade particular. A Gerencia de Configuração de Software (GCS) é para controlar mudanças e identificar as alterações feitas em softwares durante o seu desenvolvimento e manutenção. Isso permite gerenciar diferentes versões de software em desenvolvimento, permitindo que seja feita a rastreabilidade e auditoria das modificações realizadas.

Vários são os motivos para estudar e adotar a GCS. Atualmente, grandes aplicações necessitam do controle de versões, pois os engenheiros de software devem gerenciar o desenvolvimento de várias aplicações que estão sendo modificadas ao mesmo tempo e por equipes geograficamente distantes, sendo pela inserção de novos requisitos, ou por que houve um erro da aplicação em produção.

Outra motivação diz respeito às dependências que existem entre os componentes de software. Tais dependências muitas vezes são conhecidas localmente. Alguns dos desenvolvedores com esse conhecimento podem abandonar a equipe, ou serem realocados. Desta forma, devem existir meios de compartilhar o conhecimento, a fim de facilitar a manutenção do software.

Algumas atividades sobre gerência de configuração devem ser consideradas:

1 – Identificação: apóia na identificação dos componentes do software e seus tipos, tornando-os acessíveis para a equipe de desenvolvimento. A identificação também visa o mapeamento das dependências entre os seus componentes;

2 – Controle: estabelece o controle das atualizações e das mudanças no produto de software no decorrer do seu ciclo de vida. A atividade de controle deve possuir mecanismos para gerenciar e garantir a integridade da configuração do software.

3 – Geração de Estatísticas: é a geração dos relatórios de status dos componentes e dos pedidos de mudança;

4 – Auditoria e revisão: validação da completude de um produto e da integridade entre os componentes de software.

A GSC possui atividades que devem ser executadas por diversos profissionais com papéis e funções bem distintas:

- Gerente de configuração: os objetivos estão relacionados ao cumprimento de procedimentos e políticas para a criação, mudança e testes nos códigos das aplicações, bem como tornar as informações sobre os projetos mais acessíveis. Esse profissional deve implementar técnicas para manter o controle dos códigos atualizados, criando mecanismos para oficializar os pedidos das mudanças. O gerente cria e compartilha uma lista de tarefas para os Engenheiros de software, determinando o contexto do projeto de manutenção de software.

- Engenheiros de software: manter o desenvolvimento e a criação do produto de software de forma eficiente. Os engenheiros usam ferramentas que ajudam a construir um produto de software consistente, comunicando e coordenando as tarefas que foram concluídas. Um histórico da evolução de todos os componentes deve ser mantido, com o registro dos motivos das mudanças e o que realmente foi alterado. Eles também têm a responsabilidade de manter as áreas de trabalho usadas para criar, atualizar, testar e integrar os códigos das aplicações. Por fim, devem controlar a produção a produção e manutenção de código de acordo com diversas demandas de novos requisitos e a necessidade de correções geradas por erros do software em produção.

- Testador de software: Certificar se o produto de software foi desenvolvido de forma satisfatória.

Assim como todas as áreas da Engenharia de Software, a GCS necessita de soluções de software capazes de auxiliar na implementação de todas as atividades. Apesar disso, não existe uma definição universal sobre quais funcionalidades e requisitos um sistema de GCS deve possuir. Pode-se considerar que um software aplicativo que fornece controle de versão é um sistema para gerência de configuração. Outros softwares permitem registrar os pedidos de mudanças, porém muitos não integram estas funcionalidades ao controle de versão.

De maneira geral, tais sistemas devem possuir os seguintes requisitos: a) registro das versões dos componentes; b) localização das diferenças entre dois códigos modificados; c) repositórios e bibliotecas para armazenar e recuperar componentes; e, d) informações sobre diferentes tipos de componentes. Outros requisitos podem ser definidos para um sistema de GCS, como:

- Construção: os usuários precisam de meios mais fáceis de implementar o software, tendo a funcionalidade de “congelar” o status do produto em algum momento; mecanismos para otimizar os esforços da construção de sistemas; facilidades de fazer a análise dos impactos e facilitar a recuperação e geração de qualquer fase ou parte do produto.

- Auditoria: histórico de todas as mudanças; rastreabilidade; e o log de toso os detalhes dos trabalhos feitos.

- Contagem e estatística: mecanismos que registrem as estatísticas, para examinar o status do produto de software, e gerar facilmente relatórios sobre todos os aspectos do produto e processo.

- Controle: acesso cuidadoso aos componentes dos sistema para evitar qualquer mudança errada ou conflito nas mudanças; suporte on-lne para os pedidos de mudança e relatórios dos problemas; acompanhar e controlar os erros.

- Processo: suporte para seu ciclo de vida e suas políticas organizacionais; identificar tarefas para serem feitas e como e quando elas serão completadas; comunicar informações apropriadas sobre eventos relevantes; e documentar o conhecimento sobre o produto.

- Equipe: áreas de trabalho específicas; resolução de conflitos quando as mudanças são alteradas ao mesmo tempo, e facilidade para suportar a criação e manutenção de diversos produtos de software.

Um exemplo de software, usado para registrar os incidentes e modificações no software, que identifica a mudança com o preenchimento de diversas informações; possibilita o acompanhamento do processo de alteração e execução de mudanças e gera relatórios sobre a evolução dos pedidos é o Mantis.

O que é o Mantis?

Mantis Bug Tracker é uma ferramenta baseada na web que tem como principal função gerenciar defeitos de outros softwares. Ela foi escrita em PHP e funciona em diversos bancos de dados entre eles: MySQL, PostgreSQL e outros.

Gestão de Defeitos - Mantis BugTracking System

Mantis, é uma ferramenta de gestão de defeitos muito utilizada pelas empresas que adotam uma política de controle de testes e qualidade.

É uma ferramenta FREE pelos termos do GNU General Public License (GPL). Escrita em PHP, tem seu código aberto, o que permite ao usuário a possibilidade de uma grande variedade de customizações que, inclusive, são incentivadas no arquivo principal do sistema. Um grande diferencial de seus concorrentes é a possibilidade de utilização do sistema em diversos idiomas, inclusive o Português - Brasil.

São 6 níveis de usuários, (Visualizador, Relator, Atualizador, Desenvolvedor, Gerente e Administrador) cada qual possui diferentes níveis de atribuições e permições dentro do sistema, um Visualizador por exemplo pode apenas ver os registros de erros efetuados, e o Administrador tem poderes completos.

Os casos reportados (issues) são separados por projetos e sub-projetos, dessa forma ficam bem organizados dentro do sistema. Assim que são salvos, os casos são designados a um usuário, que receberá um email notificando-o como responsável pela resolução do bug. Após solucionar o erro, o responsável terá que responder ao remetente que avaliará se o caso pode ser encerrado ou não. Todas as ações são gravadas em logs que irão gerar relatórios consistentes sobre o andamento dos casos dentro de um projeto.

Com o Mantis, um gerente de projetos, por exemplo, poderá ter um controle total dos erros encontrados pelos testadores e o tempo de resposta por parte dos desenvolvedores e quais desenvolvedores estão com quais erros. Existe também uma opção que permite a um usuário acompanhar um caso e ser avisado sobre qualquer alteração no seu registro.

Estas são apenas algumas das diversas funcionalidades do sistema.

Nos próximos posts falarei mais sobre a configuração e customização do sistema.

O Mantis é uma ferramenta capaz de manter e administrar os registros e solicitações de colaboradores e usuários de sistemas e recursos de informática, facilitando o rastreamento de falhas e problemas em potencial, gerando estatísticas e documentando todo o processo de resolução das ocorrências ou problemas.

Mantis é um sistema de analise de erros opensourcebaseado em tecnologia web. Construído com base PHP funciona permite que seja uma aplicação multi plataforma.
É bastante fácil de instalar e muito flexível na sua configuração. Permite ainda especificar um numero indeterminado de estados de tarefas e atribuir perfis, programador, tester, coordenador, visualizador, etc. aos utilizadores.
Por exemplo é possível definir que apenas os testers podem declarar bugs e apenas os coordenadores os podem analisar.

O fluxo de trabalho também pode ser configurado através da ferramenta.
É uma ferramenta bastante completa e útil.

[Seminário] Prototipação no Desenvolvimento de Software

Engenharia de Software
Prototipação no Desenvolvimento de Software

Nome: Douglas Guilherme Martins 1099266349
Avelino Fernandes Neto 0950115

Prototipação no Desenvolvimento de Software
De maneira geral a Prototipação é positiva, trazendo melhoria na facilidade de uso do sistema, maior aproximação do sistema com as necessidades dos usuários, melhoria da qualidade do projeto, facilidade de manutenção e redução no esforço de desenvolvimento. Entretanto, não pode ser um processo que tome muito tempo nem esforço dos programadores. A prototipagem de sistemas tem se tornado uma pratica cada vez mais comum entre os desenvolvedores, e tem se mostrado uma alternativa interessante para a solução de vários problemas. Tem como objetivo validar os requisitos, abordar questões de interface, e avaliar tanto a viabilidade quanto a complexidade do sistema.

Protótipos de Baixa Fidelidade
Este tipo de prototipagem é aquela onde o protótipo não se assemelha com o produto final, serve somente de base para criticas. Pode ser realizado de varias formas, como ferramentas próprias ou ate um esboço feito com papel e caneta. Esse tipo se encaixa mais facilmente na fase inicial de desenvolvimento, onde ainda cabe a compreensão dos requisitos. São fáceis de construir, de custo muito reduzido, de produção extremamente rápida.

Protótipos de Media Fidelidade
Esses protótipos já possuem um nível de detalhamento maior do que os de baixa fidelidade,
porem já possuem algumas definições importantes tanto para o usuário quanto para o desenvolvedor. São feitos por ferramentas mais especificas, pois
não são somente esboços e, por isso, devem seguir critérios Nele o usuário consegue visualizar um futuro para o seu produto e o desenvolvedor já tem uma previa do produto final, e sua construção é rápida e fácil.

Protótipos de Alta Fidelidade
São aqueles que assemelham bastante ao produto final. Servem especialmente para o teste de
componentes e a solução de problemas técnicos. Um protótipo desse tipo permite pensar nos detalhes do produto bem mais a fundo do que com especificações no papel, e reduz significativamente o tempo de desenvolvimento do produto final, pois ele já esta bem mas definido, e vários problemas já foram sanados antecipadamente na contrição do protótipo Esse protótipo visa economizar mão de obra, tempo e dinheiro.

Prototipação Throw-Away (Descartável)
Esse tipo é utilizado especialmente durante a fase de levantamento de requisitos. O desenvolvedor gera uma documentação provisoria, cria um protótipo baseado nesta documentação para obter novos requisitos e validar os já implementados. Esse processo não usa a tecnologia de desenvolvimento final, e sera descartado após cumprida suas finalidades. A utilizacão desse método tem como intuito refinar a documentação para gerar qualidade
para o produto.

Prototipação Evolutiva
A prototipifica evolutiva, é utilizadas em protótipos que, através de incrementos, evoluirão ate o sistema final. São requisitos já compreendidos, visto que a Evolutiva é um método que visa a redução de custo e de tempo.
*mostrar exemplo na lousa.

Wireframes
Wireframes são documentos elaborados durante a fase de especificação de um projeto Web com o objetivo de registrar e esclarecer questões de interface, navegabilidade e usabilidade. O projeto de Wireframe pode ser considerado como um protótipo de baixa, media e alta fidelidade, podendo ser de um simples esboço ou até um contento localização, tamanho de janelas e tipos de fontes. A escolha destes atributos deve ser cuidadosa pois, dependendo dela, o projeto pode ficar muito “pobre” ou com muitos detalhes, limitando o designer a usar a criatividade.

A Ferramenta de Prototipação Axure
O Axure permite que se crie um diagrama de fluxo dos seus protótipos, protótipos do tipo wireframe e um documento de especificação contendo os detalhes dos campos existentes nas paginas dos protótipos, alem de projetos que podem ser compartilhados. Os protótipos gerados pelo Axure são paginas do tipo HTML, que podem, dependendo do projeto, ser usadas como base para a criação das paginas reais do sistema.

[Seminário] Boas Praticas na Engenharia de Requisitos

Bruno Luiz ra: 0919440340

Ronaldo Cesar ra: 0901395323

Boas Praticas na Engenharia de Requisitos

Introdução

Com os avanços tecnológicos que vem ocorrendo nas últimas décadas e a visível diminuição do custo do hardware, a informação passa a ser um recurso estratégico das empresas. O software se tornou, então, a força motora desta nova era. A integridade das informações oferecidas por um software pode diferenciar uma empresa de suas concorrentes.

O software é capaz de manipular o produto mais importante para uma empresa – a informação, e por isso é tão caro. Para evitar que a parte mais cara dos sistemas computadorizados fosse desenvolvida com baixa qualidade e pouca previsibilidade de custo e recursos, surgiram técnicas de Engenharia de Software. A Engenharia de Software surgiu com o objetivo de definir e aplicar métodos que pudessem ajudar no processo de construção, manutenção e implantação de software.

A Engenharia de Requisitos

A Engenharia de requisitos tem por objetivo definir os requisitos de um sistema em Construção e apresenta duas atividades principais: o levantamento e análise de requisitos.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível

1. Identificação.

2. Análise e negociação.

3. Especificação e documentação.

4. Validação.

O Documento de Especificação de Requisitos de Software

O DERS auxilia o clientes de software a descrever com precisão o que eles desejam, e aos desenvolvedores a entender exatamente o que o cliente deseja

Para a elaboração do DERS existe alguns padrões e praticas:

* Propósito: deve delinear o propósito particular e especificar para quem esta sendo feito esse documento

* Escopo especificar o produto a ser produzido, falando o que o produto irá fazer .

* Definições, siglas e abreviaturas: deve prover todas as definições de todos os termos, siglas e abreviaturas que são necessárias para o DERS.

* Referencias: lista de locais do DERS informando por autor, titulo, data, editora, organização, e outros atributos quando aplicáveis.

* Visão Global: explicar o que os capítulos restante irão tratar .

* Perspectiva do produto: deve colocar o produto na perspectiva de outros produtos relacionados. Se é independente. Caso contrário, se é um componente de um sistema maior, o que ocorre frequentemente, relatar as interfaces entre esse software e o sistema, e os requisitos do sistema maior para a funcionalidade deste software.

Funções do produto: um índice das principais funções que o software irá executar.

Características do usuário: descrever as características gerais do usuário do produto.

Restrições: descrever qualquer item que limite as opções do produto, como políticas de controle, limitações de hardware, interface com outras aplicações, controle de segurança, entre outros itens que forem relevantes.

Pressupostos e Dependências: listar todos os fatores que afetem os requisitos definidos

Requisitos Específicos: definição dos requisitos de software.

Todos esses tens anteriores formam os padrões indicados para a elaboração do DERS com práticas recomendadas para especificação de requisitos de software.

Requisitos Específicos: Contem a definição dos requisitos de software. É o principal capitulo do DERS, pois é nesta seção que os requisitos funcionais e não funcionais estarão definidos.

Diagrama de Casos de Uso

O Diagrama de Casos de uso tem por como objetivo mostrar graficamente todas as funções que um sistema precisara desempenhar, sempre obedecendo os padrões UML.

Objetivos

Um diagrama de casos de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.

O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema

Descrição dos Casos de Uso

Um caso de uso é escrito em linguagem natural e é constituído por uma seqüência de sentenças. Estes passos são compostos por ações simples, que descrevem o ator realizando uma tarefa ou passando informação para um outro ator. Um caso de uso tem normalmente, ao menos, dois finais possíveis, um de sucesso e outro de erro.

Um caso de uso sempre será responsável por implementar, pelo menos, um requisito funcional do sistema. Todos os requisitos funcionais do sistema devem estar ligados a um ou mais casos de uso. Essas ligações entre casos de uso e requisitos são necessárias para permitir a rastreabilidade dos requisitos.

Os fluxos são a partes principais do caso de uso. Um caso de uso deve conter todos os cenários, tanto de sucesso quanto de falha.

Algumas boas práticas para escrever um caso de uso de forma eficaz:

a) Utilizar gramática simples, pois o principal objetivo do UC é mostrar de forma clara o que sistema faz.

b) Mostrar claramente quem são os atores.

c) Incluir todas as ações, ou seja, todas as de sucesso e de falha.

d) Validar, pois deixa claro que o sistema irá validar os dados inseridos de acordo com as regras de negócio e restrições para os valores.

e) Mencionar o tempo apenas opcionalmente.

Inspeção do DERS

Inspeção do DERS (Documentos de Especificação de Requisitos de Software)

É um fator muito importante para o sucesso do DERS, avaliando o documento como um todo em busca de defeitos antes da validação junto com os clientes e usuários.

Alguns dos defeitos encontrados em um DERS:

Omissão: é todo erro relativo a alguma informação que não foi descrita.

Ambigüidade: ocorre sempre que alguma informação estiver descrita de poder causa dúvida ou confusão.

Inconsistência: é alguma sentença que contradiz algo que foi dito anteriormente no documento.

Fato Incorreto: é quando um fato descrito no DERS não é verdadeiro ou não pode ser executado.

Informação Estranha: são as informações que não pertence ao DERS.

Importante: é altamente recomendável que a inspeção seja feita por outro profissional e não pelo responsável pela criação do DERS.

Construção do DERS

O primeiro passo pra a construção do DERS é descrever todos os requisitos do sistema, logo após construir o diagrama de casos de uso que irá implementar estes requisitos antes da descrição de tais casos de uso. Após obter os requisitos, especificá-los e criar um diagrama de casos de uso, e é necessário descrever o caso de uso.

Considerações Finais

Quando um DERS é bem construído, através de sua avaliação junto aos stakeholders do projeto, é possível descobrir se os interesses dos mesmos foram corretamente entendidos, pois algumas boas praticas facilitam a criação de um caso de uso eficaz, que será capaz de fornecer aos interessados no projeto todas as informações que estes precisam, de maneira objetiva e completa.

[Seminário] - Requisitos nao Funcionais

Segue abaixo o trabalho sobre Requisitos nao funcionais de Bruno Augusto Mariano e Thiago Crisante Dias.

REQUISITOS FUNCIONAIS E ARQUITETURA DE SOFTWARE

O projeto da arquitetura de software é uma etapa essencial no desenvolvimento de sistemas de software de grande porte e complexas.

O conjunto de requisitos de um sistema é definido durante as fases iniciais do processo de desenvolvimento; tal conjunto é visto como uma especificação do que deverá ser implementado. Os requisitos são descrições de como o sistema deveria se comportar.

Outro recurso que pode ser usado pelo projetista é construir cenários. Os cenários de uso oferecem suporte a requisitos específicos e visam tanto a licitação quanto a analisar os requisitos.

O desenvolvimento de um sistema de software inicia-se com um arquiteto de software, de posse de um conjunto de requisitos de sistema; nesse momento busca-se identificar qual estilo ou combinação oferece um suporte mais adequado a esses requisitos e, derivar uma arquitetura de software que atenda as características do sistema que se queira desenvolver.

A complexidade de um sistema de software é determinada tanto por requisitos funcionais (o que ele faz), quanto por requisitos não funcionais (como ele faz).

O Requisito Funcional de um sistema de software especifica uma função que o sistema ou componente deve ser capaz de realizar, estes são requisitos que definem o comportamento de um sistema, ou seja, processo ou transformação que os componentes de software ou hardware efetuam sobre as entradas para produzir saídas.

O Requisito não Funcional é aquele que descreve como o sistema fara uma determinada tarefa e não o qual tarefa ele fara. A avaliação dos requisitos não funcionais é feita em parte por meio de testes, enquanto que a outra parte é avaliada de um jeito subjetivo.

Tanto os requisitos funcionais quanto os não funcionais possuem grande importância no desenvolvimento de um sistema de software.

REQUISITOS NÃO FUNCIONAIS

São aqueles que não estão diretamente relacionados a funcionalidade de um sistema, chamados também de atributos de qualidade. Os requisitos não funcionais possuem um papel de grande importância durante o desenvolvimento de um sistema, podendo ser usados como critérios de seleção na escolha de alternativas de projeto. Os requisitos não funcionais abordam aspectos de qualidade importantes em sistemas de software, se tais requisitos não são levados em consideração, então o sistema de software poderá ser inconsistente e de baixa qualidade.

Ao desenvolver um novo sistema de software os projetistas apresentam um conjunto de atributos de qualidade ou requisitos não funcionais que o sistema deveria suportar. Exemplos destes requisitos podem ser o desempenho, portabilidade, manutenibilidade e escalabilidade.

A estruturação de um sistema é determinante no suporte oferecido a um requisito não funcional. o uso de camadas permite melhor separar as funcionalidades de um sistema, tornando-o mais modular e facilitando sua manutenção.

Na figura abaixo segue um exemplo de subconjunto de requisitos não funcionais denominados de requisitos de produtos os quais estão associados à arquitetura de um sistema de software. :

USABILIDADE

Usabilidade é um dos atributos de qualidade ou requisitos não funcionais de qualquer sistema interativo, no qual ocorre interação entre o sistema e seres humanos. A noção de usabilidade vem do fato que qualquer sistema projetado para ser utilizado pelas pessoas deveria ser fácil de aprender e fácil de usar.

Requisitos de usabilidade especificam tanto o nível de desempenho quanto a satisfação do usuário no uso do sistema. A usabilidade pode ser expressa em termos de:

Facilidade de Aprender – Associado ao tempo e esforço mínimo exigido para alcançar um determinado nível de desempenho no uso do sistema.

Facilidade de Uso – Relacionado à velocidade de execução de tarefas e à redução de erros no uso do sistema.

MANUTENIBILIDADE

O termo manutenção de software é geralmente empregado quando nos referimos às modificações feitas após o sistema de software ter sido disponibilizado para uso.

O termo manutenibilidade envolve tanto a atividade de reparo quanto a atividade de alteração/evolução de características existentes ou adição de novas funcionalidades não previstas ou capturadas no projeto inicial.

O reparo de um sistema de software ocorre quando defeitos são detectados, fazendo-se necessária a correção deles. Se o sistema é monolítico, ou seja, constituído de um único componente, então tornar-se mais difícil efetuar o reparo se este sistema de software é de grande porte. Se o sistema de software é modularizado, então tende a ser mais fácil analisar e reparar o existente.

CONFIABILIDADE

É a probabilidade de o software não causar uma falha num sistema durante um determinado período de tempo sob condições especificadas. A probabilidade é uma função da existência de defeitos no software. A confiabilidade de software, é a probabilidade de que o software irá operar como desejado num intervalo de tempo conhecido. Também, a confiabilidade caracteriza-se um atributo de qualidade de software o qual implica que um sistema executará suas funções como esperado. Geralmente, as falhas de um componente de software são de natureza transitória, elas ocorrem apenas para algumas entradas enquanto o sistema poderá continuar operando normalmente em outras circunstâncias. Isto distingue o software do hardware já que as falhas no segundo são de natureza permanente.

DESEMPENHO

Desempenho é um atributo de qualidade importante para sistemas de software.

Note que os requisitos de desempenho têm impacto mais global sobre o sistema e, por essa razão, estão entre os requisitos não funcionais mais importantes. Contudo, é geralmente difícil lidar com os requisitos de desempenho e com outros requisitos não funcionais, uma vez que eles estão em conflito.

O requisito de desempenho - Restringe a velocidade de operação de um sistema de software. Isto pode ser visto: num caixa eletrônico, após o usuário inserir o cartão magnético do banco no local apropriado (leitor do equipamento), o sistema deveria exibir uma nova tela, num intervalo de 2 segundos.

Requisitos de processamento - especificam a quantidade de dados que deveria ser processada. Um exemplo seria exigir que o sistema de software possa processar, no mínimo, 6 transações por segundo.

Requisitos de temporização – O sistema deveria coletar dados de entrada de sensores antes que outras leituras de dados de entrada. Assim, por exemplo, poderia efetuar leitura de dados 5 vezes por segundo, como condição mínima.

Requisitos de espaço – Os requisitos de espaço podem ser considerados. Aqui, podemos nos referir à memória principal ou secundária. Por exemplo, a memória principal para executar uma aplicação poderia ser considerada como um requisito de desempenho.

Neste caso, os mecanismos de comunicação utilizados pelos componentes de um sistema têm influência sobre o desempenho obtido.

REUSABILIDADE

Uma característica das engenharias é fazer uso de projetos existentes a fim de reutilizar componentes já desenvolvidos. Na indústria de automóveis, por exemplo, um motor é geralmente reutilizado de um modelo de carro para outro.

O reuso pode ser visto sob diferentes perspectivas

• Aplicação – Toda a aplicação poderia ser reutilizada.

• Subsistemas – Os principais subsistemas de uma aplicação poderiam ser reutilizados.

• Objetos ou módulos – Componentes de um sistema, englobando um conjunto de funções, podem ser reutilizados.

• Funções – Componentes de software que implementam uma única função (como uma função matemática) podem ser reutilizados.

É importante observar que podemos obter ganhos se reutilizarmos tanto projetos quanto arquiteturas. Isto minimiza esforços de desenvolvimento e requer menos alterações ou adaptações.

Assim, o requisito reusabilidade pode envolver a arquitetura. O que determinará quão fácil será conseguir componentes reutilizáveis

SEGURANÇA

Em um sistema de software, este requisito não funcional caracteriza a segurança de que acessos não autorizados ao sistema e dados associados não serão permitidos.

Dessa forma, a segurança é vista como a probabilidade de que a ameaça de algum tipo será repelida.

Exemplos de requisitos de segurança são:

• Apenas pessoas que tenham sido autenticadas por um componente de controle tipo de acesso apenas às pessoas autorizadas.

• As permissões de acesso ao sistema podem ser alteradas apenas pelo administrador de sistemas.

• Deve ser feito cópias em um local seguro, sendo preferencialmente num local diferente de onde se encontra o sistema.

• Todas as comunicações externas entre o servidor de dados do sistema e clientes devem ser criptografadas.

Os requisitos não funcionais de segurança envolvem diferentes aspectos.

Disponibilidade – Refere-se a assegurar o sistema contra qualquer interrupção de serviço.

Integridade – O foco na integridade ocorre principalmente em sistemas comerciais, onde se busca assegurar que acesso ou atualizações não autorizadas ocorram.

Confidencialidade – A ênfase aqui é a de não permitir a revelação não autorizada de informações.

Segurança operacional – Refere-se à fase considerada para o sistema em uso.

1. Identificação – Identifica o nome do usuário.

2. Autenticação – Visa assegurar que os usuários são, de fato, quem afirmam ser.

3. Tempo de acesso – Busca limitar o tempo de acesso ao sistema a fim de reduzir qualquer tipo de ameaça.

4. Auditoria de segurança – Objetiva habilitar pessoal autorizado a monitorar o sistema e, seletivamente,rastrear eventos importantes.

5. Alarme – Esta operação visa prevenir acessos, notificando esses acessos à supervisão de segurança.

CONCLUSÃO

Requisitos funcionais e não funcional é etapa fundamental no desenvolvimento de sistemas.

Cabe destacar que, quando da análise de arquiteturas candidatas para um sistema de software, um arquiteto ou engenheiro de software considera os requisitos não funcionais como um dos principais critérios para sua análise.

[Aula] Requisitos de Software

 Na última aula, realizada em 28/02, foram apresentados os conceitos de Requisitos de Software.

 Como leitura complementar, sugiro o seguinte documento:

Analise de Requisitos Software


  E para distrair, segue uma tirinha do Dilbert:

Uma excelente semana a todos!!!

[ATPS] ATIVIDADES PRÁTICAS SUPERVISIONADAS ETAPA 1

VETSOFT ALL

Um novo software de gerenciamento para sua clínica veterinária CLIVET. Desenvolvido para atender as novas necessidades de sua clínica veterinária, ele se preocupa não somente em “guardar” os dados e informações dos clientes e animais, e sim fazer com que essas informações se transformem na principal ferramenta de trabalho Da CLIVET.

Queremos transformar esse relacionamento entre o Clínico e o seu Cliente em uma relação duradoura, traçando um Plano de Vida baseado na Medicina Veterinária Preventiva. Fundamentado nesse conceito, oferecemos ferramentas que irão facilitar e revolucionar o uso do software de gerenciamento de sua Clínica Veterinária.

O formato criativo de apresentação de todas as informações “dados” do Cliente e animal em uma mesma e principal página se mostra de fácil visualização e entendimento, pois em uma única visualização você pode ter todas as informações sobre o seu cliente, o seu animal, todo o seu histórico de relacionamento e tratamento assim como o seu status contábil. Nessa mesma página além da agenda de retornos, baseados no Plano de Vida dos seus animais previamente traçado levando em consideração a idade cronológica dos animais. Essa ferramenta permite que automaticamente você tenha todas as informações dos próximos procedimentos programados durante toda a vida do animal e daqueles que não foram realizados, uma vez que do lançamento no histórico do animal do procedimento realizado, os lembretes se atualizarão automaticamente. Tendo em mãos as informações dos clientes, dos animais e os procedimentos programados.

CARACTERISTICA 1

Abertura do Sistema:

Tela de Acesso ao sistema Acesso com usuário e senha.

Cadastros Básicos: Cadastro de Funcionários, usuários e senhas: Cadastro de Funcionários, usuários e senhas de acesso ao sistema, Controle de permissões do nível de acesso de cada usuário cadastrado, os funcionários são cadastrados separados por funções.

Cadastro de Clientes: Dados cadastrais do cliente, Informações adicionais, limite de crédito, Animais do cliente.

Cadastro de Animais: Dados cadastrais do animal, Observações do Animal, Álbum de fotos é possível adicionar infinitas fotos do animal.

Cadastro de Fornecedores: Dados cadastrais do fornecedor, Histórico de compras do fornecedor, aqui é exibido todas as compras realizadas com este fornecedor, Ficha cadastral do fornecedor, é possível imprimir todos os dados do fornecedor para arquivar em uma ficha.

Cadastro de Produtos: Listagem / Pesquisa de Produtos, os produtos são separados por grupos, Dados cadastrais de um produto, Histórico de compras do produto, Histórico de Vendas do produto, Movimentação de Estoque do produto (compras, vendas, ajuste de estoque e devolução).

CARACTERISTICA 2

Controle de Estoque:

Lançamento de Notas de compra (entrada de produtos no estoque): Listagem de todas as notas de compras lançadas no sistema, Registrando uma nota de entrada de mercadorias, Programando pagamentos de uma compra de produtos.

Ajuste de Estoque (quantidades e preços) e Reajuste automático de preços: Ajuste de estoque, aqui você pode alterar preços e quantidades de estoque dos produtos de uma forma rápida e eficiente, Reajuste automático de preços, você informa os parâmetros e o sistema recalcula os preços.

CARACTERISTICA 3

Módulo de Vendas:

Dados de Vendas: Abertura de caixa, Registrando a venda de um serviço, escolhendo funcionário que executou e determinando sua comissão, Integração com o módulo de agenda, Fechamento do caixa.

Impressão de Etiquetas de código de barras dos produtos: Seleção de Produtos e quantidade de etiquetas para cada produto, Seleção do modelo de etiqueta (todos modelos podem ser personalizados), Visualização da impressão de etiquetas.

CARACTERISTICA 4

Módulo Financeiro:

Contas a pagar (integrado com compras de produtos): Calendário de contas a pagar, Dados de uma conta a pagar, Relatórios de contas a pagar.

Contas a Receber (integrado com débitos dos clientes): Calendário de contas a receber, Listagem geral de contas a receber, Dados de uma conta a receber.

CARACTERISTICA 5

Módulo de Agendamento:

Listagem da agenda: Grade de exibição dos serviços agendados por data e horário, Listagem geral de serviços agendados, Agendando um serviço (com impressão de comanda para uso interno), Agenda de Telefones.

Relatórios do sistema:

Modulo de Relatórios: Todos os relatórios podem ser gerados em MS-Excel.

Módulo de Segurança:

Backup: Módulo de Backup do Sistema.

	VETSOFT SILVER	VETSOFT GOLD	VETSOFT PLATINUM
CARACTERISTICA 1	PP	P	P
CARACTERISTICA 2	PP	P	P
CARACTERISTICA 3	PP	PP	P
CARACTERISTICA 4	NA	PP	P
CARACTERISTICA 5	NP	NA	P

	VANTAGENS	DESVANTAGENS
VETSOFT SILVER	CUSTO BAIXO	LIMITADO A POUCOS RECURSOS
VETSOFT GOLD	CUSTO BENEFICIO	SEM SUPORTE A ATUALIZAÇÕES POSTERIORES
VETSOFT PLATINUM	SUPORTE A ATUALIZAÇÕES SEM CUSTO	NÃO TEM