[Seminário] Análise de Pontos de Função

Análise de ponto de função

Aplicações para estimativas de tamanho de Projetos de Softwares

DEFINICAO

Análise de Pontos de Função (APF) é a técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seus usuários. Ponto de função (PF) é a sua unidade de medida, que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a APF busca medir o que o software faz, e não como ele foi construído.

BREVE HISTORIA E SEUS OBJETIVOS

A APF surgiu em 1979 como resultado de um projeto desenvolvido por Allan Albrecht, pesquisador da IBM. O objetivo era encontrar uma técnica de estimativa para esforço de desenvolvimento de software que fosse independente da linguagem de programação utilizada. Apesar de ter surgida na IBM, o resultado desse projeto foi aberto à toda comunidade de software em 1984. Ou seja não é propriedade de nenhuma empresa.

ORGAO RESPONSAVEL PELA PADRONIZACAO DA TECNICA APF

O padrão reconhecido pela indústria de software para APF é o Manual de Práticas de Contagem de Pontos de Função (CPM - Counting Practices Manual) mantido pelo IFPUG - International Function Point Users Group.

O IFPUG é uma entidade sem fins lucrativos composta por pessoas e empresas de diversos países cuja finalidade é promover um melhor gerenciamento dos processos de desenvolvimento e manutenção de software através do uso da APF.
No Brasil o órgão responsável pela padronização é: BFPUG - Brazilian Function Point Users Group.

PRIMEIROS PASSOS PARA A APLICACAO DA APF

O primeiro passo é identificar claramente quais os objetivos da organização. A APF pode ser empregada com várias finalidades: estimativas de projetos de software, unidade de medição de contratos, apoio ao controle de qualidade e produtividade, benchmarking e programa de métricas.

ONDE PODEMOS UTILIZAR A APF

APF é uma técnica independente da tecnologia utilizada para modelar ou implementar um software. Portanto um software terá o mesmo tamanho em pontos de função quer venha a ser desenvolvido utilizando tecnologia OO (Orientada ) ou uma outra abordagem.
O que poderá diferenciar as duas abordagens é que no projeto OO a produtividade (hora/PF) poderá ser melhor devido ao reuso. Fazendo uma analogia com a construção civil: pode-se construir uma casa de 100m2 da maneira convencional ou utilizando módulos pré-fabricados. Em ambos os casos o tamanho da casa será o mesmo, apenas o tempo de construção ou o custo poderá variar.

HOUVE ALGUMA EVOLUCAO NA TECNICA DA APF APÓS SUA CRIACAO?

Sim, desde a publicação da proposta da APF em 1979 diversos refinamentos foram incorporados à técnica ao longo dos anos. E este processo ainda continua. Porém a essência da técnica mudou muito pouco. Isto resulta do fato da técnica ser orientada à medir a funcionalidade que um software fornece ao usuário, independente da plataforma tecnológica na qual o software rodará, metodologia de desenvolvimento ou linguagem de programação usada para sua construção.

E NECESSARIO SER DESENVOLVEDOR DE SOFTWARE (ANALISTA DE SISTEMAS, PROGRAMADOR, ETC) PARA APRENDER OU USAR A APF ?

Não. A grande vantagem da APF é que ela é baseada na VISÃO DO USUÁRIO, permitindo que seus conceitos possam ser compreendidos tanto pelo desenvolvedor quanto pelo usuário. O objetivo da técnica é medir a funcionalidade que o software fornece ao usuário independente da tecnologia usada para a implementação do mesmo. Essa medição é baseada somente nos requisitos que o software deve atender.

QUEM USA APF NO BRASIL E NO MUNDO ?

No Brasil pode-se citar empresas como Accenture, Bradesco, Companhia Vale do Rio Doce, Caixa Econômica Federal, Correios, CPM, Datamec, Datasul, DBA, EDS, IBM, Petrobras, Politec, Tata, Unibanco, Unisys, Xerox, dentre outras.
O IFPUG possui filiados de mais de 40 países; sendo que o uso da APF é mais intenso na Alemanha, Austrália, Brasil, Canadá, Coréia, Estados Unidos, Índia, Inglaterra, Itália e Holanda. Exemplos de outras empresas no mundo que usam a APF: IBM, Unisys, Xerox, EDS, Citigroup, Tata, Lockheed Martin-EIS, Booz Allen & Hamilton, Nielsen Media Research, Bank of Canada, Ralston Purina Co., Northrop Grumman Corp, Samsung SDS Co Ltd, BASF Corporation, Accenture, Pepsi Co, Compuware, Pricewaterhouse Cooper.

QUE DOCUMENTOS SAO NECESSARIOS PARA UMA CONTAGEM DE PONTOS DE FUNCAO ?

Não há um documento específico de uso obrigatório para se medir um software (ou contar pontos de função). Qualquer documento no qual seja possível extrair informações dos requisitos do usuário pode ser usado em uma contagem de pontos de função. Sejam eles casos de uso, manuais, protótipos, documentos de visão, modelo de dados, modelo de classes, etc. Isto é coerente com o próprio objetivo da APF que é ser uma técnica independente da implementação do software. Pode-se implementar um software através de diferentes métodos e ferramentas para análise, modelagem e construção, para diversas plataformas computacionais; mas nada disso afeta a medição do mesmo em pontos de função.

É claro que determinados tipos de documentos podem trazer a informação necessária para uma contagem de pontos de função de maneira mais fácil. Outros documentos podem conter apenas parte da informação necessária para a contagem de PFs, sendo necessário a análise conjunta de mais documentos para se efetuar a medição. Assim como também outros documentos, por terem um caráter mais técnico para o processo de desenvolvimento de software, podem dar mais trabalho para se extrair os requisitos do usuário. O melhor documento para se utilizar numa contagem de PFs é aquele que contém os requisitos do usuário explicitados na linguagem do seu negócio, e não num linguajar de TI.

Cada organização possui o seu processo de desenvolvimento particular, produzindo uma quantidade de documentos (ou artefatos) distintos em determinadas fases do processo. Logo, o momento no qual a medição é feita acaba determinando também quais documentos estarão disponíveis para se efetuar o trabalho de medição (ou estimativa) do tamanho funcional do projeto.

Danilo F. da Silva - R.A 1814319815
Marcio C. Veiga - R.A 1814319847

[ATPS 2] ETAPA 2-Engenharia de Requisitos.

Motivação !

• Oportunidade concreta e eficiente de expandir os negócios !

“Indústria de calçados redescobre mercado interno e amplia produçãoCom crise abrandada, setor se volta ao Brasil para atender demanda.No primeiro semestre de 2010, crescimento das vendas foi de 7%.”

“Comércio exterior: As vendas para o mercado externo também estão animando a indústria brasileira. De janeiro a junho deste ano, em relação ao mesmo período de 2009, foi registrado um crescimento de 12,1% no faturamento (US$ 627,6 milhões) do setor. Quanto ao número de pares exportados, o incremento chegou a 21,4% de janeiro a maio deste ano, 69,4 milhões, em comparação ao ano anterior, segundo Abdala.”

(Dados coletados na imprensa Anay Cury DO G1, em São Paulo )

Dados coletados Entrevista :

• Data e período da pesquisa ?

- 13/09/2010

- Realizada entre 21:50 ás 22 :20 hs

• Qual o ramo da empresa?

- Industria de Calçados e Varejo

• Quantas e pessoas trabalham na empresa?

- A empresa se constitui em : uma fabrica e duas lojas .

- Aproximadamente 10 funcionários em cada loja e 8 na fabrica .

• Dados pessoais do entrevistado ?

- Tânia Ramires

- Sócia Majoritária

• Quais serviços você desempenha ?

- Gerencia de Vendas e Negócios

- Gerencia das principais tomadas de decisão

Sobre Sistema atual da Empresa:

• Já possui um Sistema na Empresa ? Qual?

- Sim , Microsoft Office

- Usado para manter dados importantes:

- Produção

- Vendas

- Fornecedores

- Os clientes são cadastrados em um fichário de papel.

• Como é o parque tecnológico existente?

- Possui 9 no total , sendo 3 em cada unidade

- Desktops Dell Dimension 1000

- Processador AMD Athlon X2 7550

- Memória 3GB DDR2 800MHz

- Monitor Dell 19 polegadas – Widescreen

- Disco Rígido SATA de 500GB (7200RPM)

- Gravador de DVD/CD Slot-Load Integrado

-Windows 7 Home Basic 32-bit em Português

• Haverá migração de dados? Em que estruturas estão esses dados?

- Sim, dados de clientes, produtos e fornecedores.

- Estão armazenados em Banco de Dados Microsoft Access

Soluções para novo Sistema :

• Quais os principais problemas da empresa?

-Controle dos produtos fabricados

-Quantidade de fabricação por lotes.

-Controle sobre as vendas

-Quantos produtos foram vendidos.

-Controle de compras

-Quais matérias primas faltam para a produção de sapatos.

-Controle de Estoque

-Gerenciar entregas

-Controlar entrada e saída de matéria prima.

-Controlar entrada e saída de produto fabricado.

• Quais são as expectativas em relação esses problemas?

- Automatização e armazenamento da informação

- Planejamento com base em relatórios efetivos

- Redução de custos e estoques

• Qual a visão do sistema a ser desenvolvido?

- Dados e informações compartilhadas por toda companhia gerando integração e velocidade de comunicação entre os processos de negócio por toda a empresa,

• Quais facilidades esperadas do sistema?

- Suprir as expectativas em relação a usabilidade

- Melhoria da produtividade

- Melhoria da qualidade

- Melhoria dos serviços prestados aos clientes

- Redução dos leads times e do tempo de resposta ao mercado

- Melhoria do planejamento e alocação de recursos

- Reorganização e perpetuação dos processos de negócio

• O sistema deverá suprir quais departamentos?

finanças: sim(x) não ( )

fabricação: sim(x) não ( )

estoque sim(x) não ( )

marketing: sim(x) não ( ) “obs.” Relatório Brindes

vendas: sim(x) não ( )

compras: sim(x) não ( )

• Outros setores? Quais?

- Devera atender futuramente seus clientes e fornecedores pela WEB

- Devera suprir futuramente controle de funcionários (RH)

• Quais informações estratégicas deverão estar disponíveis ?

- Fabricação / Produção

- Matéria prima

- Compra /Pedido

- Fornecedor

- Cliente Vendas /Pedido

- Entrega Estoque

• Em que ambiente essa solução deverá funcionar?

- Linux, Código fonte aberto.

• Como esta estruturada a equipe de TI?

- Prestação terceirizada

• Qual a visão de longo prazo para o produto?

- Atender a demanda de vendas e crescimento no setor .

- Tornar a leitura dos dados organizados e estruturados

- Relatórios estatísticos e precisos

- Web para visibilidade no mercado competitivo

• Em quanto tempo seria ideal a conclusão do projeto?

- 6 Meses para entrega de sistemas e soluções desejadas

• Qual é a previsão desse investimento?

- “Dinheiro não é problema”

Com base na entrevista na entrevista!

ERPCamp oferece

Especificamente construído para fabricantes e varejistas operações robustas e capacidade gerencial de gerenciamento financeiro multinacional.O Sistema composto de soluções que integram todos os dados e processos de uma organização em um único sistema simplificam o desenvolvimento do projeto e do produto, modernizam a terceirização e o gerenciamento de amostras e automatizam vendas para que você possa exibir suas novas criações e tornar a elaboração de pedidos mais fácil.têm como objetivo automatizar os processos dentro de uma empresa, integrando as informações através da organização, eliminando interfaces complexas entre sistemas não projetados para conversarem. Desta maneira, todos os processos de uma empresa são alocados dentro de um mesmo sistema e em uma mesma base de dados, integrando-os e interagindo com todas as aplicações no sistema.

FUNCIONALIDADES DO ERPCamp

Conheça o que nosso software pede fazer pelos deptos abaixo:
- Controle e gerenciamento de informações
- Controle do depto de compras/estoque
- Controle do depto de vendas
- controle do depto financeiro
- Controle do depto de marketing
- Controle de ferramentas gerenciais

BENEFÍCIOS DO ERPCamp

- Acesso à informação tratada com mais agilidade;
- Acesso à informação mais detalhada e proveniente de várias áreas da empresa;
- Menor tempo de resposta e assistência ao cliente;
- Maior controle nos dados de entrada;
- Melhor monitoração do sistema e maior rapidez nas consultas às bases de dados;
- Fornecimento de uma única base de dados a ser utilizada por todas as aplicações;
- Acesso à informação e/ou gerência de processos através de qualquer terminal presente em todos setores da organização;

- Redução de custos e produzir melhores resultados financeiros;
- Diminui significativamente os retrabalhos, a entrada de dados e digitação;
- Organiza e disponibiliza as informações;
- Comprar o material necessário,considerando os diversos fornecedores, conforme a necessidade líquida do estoque;
- Tomada de decisões estratégicas com maior rapidez, tendo confiabilidade e segurança por meio de planejamento;
- Entrega de pedidos no prazo correto e até mesmo antecipá-los;
- Otimiza os gastos de TI;
- Melhora o planejamento no depto de compras, reduzindo o nível de estoque;
- Evita compras desnecessárias e controla desperdícios;
- Melhora o atendimento aos clientes conforme suas expectativas e necessidade

Thiago Cambiaghi dos Santos / 0850334

Marcelo Machado Gomes / 1801271201

José Dorival Jorge Junior /1801281219

[ATPS 2] Engenharia de Requisitos

Visão Geral do Sistema
Precisa se de um sistema para controle da produção e vendas integrado entre as lojas e fabrica de calcados, visando principalmente o controle de estoque de matérias primas e produtos, gerenciamento de entregas, controle de PDV, cadastros de produtos, materiais primas, vendedores, fornecedores e clientes. O cliente exige também a geração dos relatórios de entrada e saída de matérias primas, saída de produtos, vendas, clientes, produção, e brindes possivelmente concedidos a clientes, listagem de produtos em promoção no momento e geração de arquivo XML de notas fiscais emitidas uma vez ao dia para envio a receita federal.
O cliente exige que o sistema tenha interface web e seja hospedado em um Data Center, no entanto, será disponibilizado apenas na intranet por enquanto, com possibilidades futuras de integração com a extranet para disponibilizar ao cliente a possibilidade de compras e visualizações de produtos on-line. Devera ser levado em consideração para desenvolvimento plataforma operacional Windows com uma media de 40 usuários simultâneos com possibilidade de expansão, dever-se-há considerar também a possibilidade de expansão da empresa para o mercado exterior.
O cliente expôs que, espera um produto de fácil uso devido à falta de familiaridade de seus funcionários com computadores, e que as informações disponibilizadas sejam verídicas, para tanto são necessárias atualizações instantâneas dos dados, ele exige também a entrega do código fonte no ato da entrega do produto.
OBS:
Foi acordado que prioritariamente deveram ser desenvolvidas as funcionalidades para controle de estoque de matérias primas e entregas cujos quais dependem do cadastro de fornecedores e de produtos; e gerenciamento das entregas para as quais foi fixado um prazo Maximo de entrega de seis meses.
Requisitos funcionais:
1. Registrar de entrada de matéria prima;
2. Registro de saída para consumo de matéria com notificação de estoque crítico;
3. Registrar de produção;
4. Gerenciar de entregas;
5. Controle de PDV;
6. Gerenciar preços;
7. Gerenciar cadastro de produtos;
8. Gerenciar cadastro de matérias primas;
9. Gerenciar cadastro de fornecedores;
10. Gerenciar cadastro de vendedores;
11. Gerenciar cadastro de clientes;
12. Gerar de nota fiscal eletrônica;
13. Gerar de arquivo XML das notas fiscais emitidas;
14. Registrar a entrega de brindes;
15. Gerar promoções;
Requisitos não funcionais;
1. O sistema deve ter interface web;
2. O sistema deverá ser hospedado em um Data Center;
3. O sistema devera funcionar apenas na intranet;
4. O sistema devera suportar plataforma Windows;
5. As atualizações no banco devem ser em tempo real;
6. A segurança deverá ser em nível de usuário;
7. Tempo de entrega das duas primeiras funcionalidades no Maximo seis meses;
8. Entrega do código fonte ao cliente.

Principais Funcionalidades
1. Controle de entrada de matéria prima:
O controle de entrada de matéria prima trata-se do registro de entrada com fundamentação para a alimentação do estoque de matérias prima, no entanto a entrada de matéria prima deverá ser fundamentada, para tanto e necessário o registro da data de recebimento, dados da NF, quantidade, valor e tributos relacionados.
2. Controle do consumo de matéria prima:
Para controle real do estoque de matéria prima necessita–se do registro de saída de matéria prima pêra a produção esta funcionalidade basicamente proverá uma forma de registro de saída de matéria prima para a produção com a possibilidade de notificação em caso de estoque crítico ou a geração de relatório diário.
3. Controle da produção:
Para maior controle da gerencia quanto à produção faz se necessário a geração de relatórios atualizados de produção e estoque, portanto, faz-se necessário uma funcionalidade onde o responsável pela produção deverá registrar a produção diária.
4. Controle de entregas:
O controle de entrega nada mais e do que um controle de saída de produtos, com a finalidade principal de atualização de estoque e possivelmente poderá ser usado para a geração de notas fiscais.
5. Controle de PDV:
O controle de ponto de venda trata-se do registro das vendas e controle de entrada de caixa nas lojas, atualizando o estoque no momento do registro da venda, e emissão de cupons fiscais, isso claro levando-se em consideração a legislação vigente.
6. Gerenciador de preços:
Para a atualização dos preços de venda, é necessária uma funcionalidade onde o usuário poderá alterar o preço dos produtos, bem conveniente será se trouxer ao usuário informações de margens de lucro bruto e liquido e sugestão de preço á praticar.
7. Cadastro de matérias primas:
O cadastro de matérias primas e a funcionalidade onde o usuário poderá inserir ou alterar o cadastro de uma matéria prima e seus atributos, poderá trazer também informações sobre o produto que dará origem e a unidade de sua medida.
8. Cadastro de fornecedores;
O cadastro de fornecedores devera ter o CNPJ/CPF, Razão Social e endereço completo como campos obrigatórios, no entanto faz-se necessário uma funcionalidade onde todos os dados exigidos pelo cliente sejam gerenciados por ele.
9. Cadastro de produtos:
O cadastro de produtos basicamente e uma funcionalidade onde o usuário poderá inserir ou alterar o cadastro de produtos para posteriormente disponibilizar suas informações para uso do sistema ou do usuário.
10. Cadastro de vendedores:
Na funcionalidade do cadastro de vendedores deverá haver as informações fundamentais que o sistema e o usuário necessitam.
11. Cadastro de clientes:
Basicamente a funcionalidade do cadastro de cliente e o registro do cliente no sistema levando em consideração seus atributos necessários para a geração das informações esperadas.
12. Geração de nota fiscal eletrônica:
Para o registro legal de uma transação de mercadorias faz-se necessário a emissão de nota fiscal eletrônica como se especifica a legislação vigente, para tanto poderá ser utilizado a interface de controle de entregas (na fábrica) ou através de uma funcionalidade especifica para as lojas usando como base os dados do cupom fiscal emitido no caixa.
13. Geração de arquivo XML das notas fiscais emitidas:
Para prestação de contas com a receita federal e necessária uma funcionalidade que permita exportar os dados das notas fiscais emitidas em formato XML não sendo definida ainda a forma de envio dos mesmos.
14. Controle de brindes:
Para o controle dos brindes concedidos há cliente deverá haver uma funcionalidade onde o usuário deverá registrar a entrega dos brindes que devera conter dados do cliente e do brinde, alem de data, numero do cupom fiscal e outras informações que sejam peculiares.
15 Gerar promoções:
Esta funcionalidade e para que o gerente da loja possa gerar uma promoção de produtos.
OBS:
Para todas as funcionalidades acima e necessário levar em consideração para caso de ocorrência de erros de entrada de dados que o sistema não pode detectar, portanto dever-se-há permitir o cancelamento da entrada de dados, isso relacionado à vontade e permissão do usuário do sistema.

Restrições do Sistema
1. Interface:
O sistema deverá por exigência do cliente, ter interface web isso quer dizer que deverá funcionar nu sistema de domínio podendo ser acessado a qualquer hora e de qualquer lugar através de um browser que permita acessar a pagina do domínio da empresa.
2. Disponibilidade:
Para maior conforto e segurança do cliente acertou-se a hospedagem do sistema em um Data Center cuja alocação física e backups será de inteira responsabilidade da locadora do serviço.
3. Expansão:
Apesar de ser um sistema web o serviço deverá no momento ser disponibilizado apenas na intranet, sendo futuramente possível a disponibilidade ao cliente via web para compras e consulta de produtos.
4. Plataforma:
A plataforma definida para o funcionamento do cliente e o sistema operacional Windows por se ser o sistema operacional de uso atualmente no hardware da empresa.
5. Integridade:
Para não haver inconsistência de dados as atualizações dos dados no banco de dados deverá ser instantânea.
Exemplo:
No caso de uma consulta ao estoque disponível um item em transito de venda não poderá ser disponibilizado, poderá haver então estoque atual e disponível para definir a situação do item.
6. Segurança:
Para nível de segurança deverá haver a autenticação dos usuários do sistema através de nome e senha, sendo o seu acesso aos dados completamente controlados por um administrador que poderá conceder ou revogar concessões ao usuário.
7. Tempo de entrega:
Para as funcionalidades de Controle de entrada de matéria prima e Controle do consumo de matéria prima o prazo máximo fixado para entrega e de seis meses.
8. Usabilidade:
O cliente exige telas leves e de fácil compreensão devido principalmente a limitações dos usuários;

Relatórios
1. Entrada de matérias primas e Saída de matérias primas para consumo:
Precisa se de um relatório que possa trazer informações de quantidade de entrada, valores, valor médio no período, estoque atual disponível e que seja parametrizável pelo usuário e realize busca por período, itens gerais e item específico.
2. Saída de produtos para entrega:
O para o relatório de saída de produtos para entrega as informações do destino, quantidade, valor, totais do período pesquisado em moeda e em produtos responsáveis e data são imprescindíveis, levando em consideração os pontos parametrizáveis pelo usuário que podem ser item por período ou itens gerais num período determinado.
3. Vendas:
Precisa se de um relatório de vendas capaz de trazer informações de vendas de itens individual, geral por período, por vendedor, itens promocionais sendo estes definidos por opções parametrizáveis pelo usuário com informações adicionais de total do período, preço médio por item.
4. Clientes:
Deve informar clientes ativos, compras no período, valor médio gasto sendo parametrizável pelo usuário para relatório geral num período ou por um cliente especifico podendo relatar a ultima compra e valor gasto.
5. Produção:
Informação de produção pó item num período ou totais de todos os itens produzidos num período, calculando o valor médio por produto produzido e valor total do período;
6. Brindes possivelmente concedidos a clientes:
Informações do cliente que recebeu o brinde, valor da compra na oportunidade, valor do brinde, nome do responsável, data e outros com possibilidade de parametrização para uma busca por brinde, responsável, cliente ou total no período.
7. Produtos em promoção no momento.
Informações de produtos em promoção no momento, valor praticado valor promocional, valor arrecadado no período e total vendido no momento.


Nome: Carlos Alessandro soares Ra: 1801241420
Nome: Claudio Marcio Gonçalves Ra: 1801241420
Nome: Elizete Nerick Ra: 0850254

[ATPS 2] Trabalho ATPS

Nome: Joyce Ra:0850320 Lilian 180005269

Controle de Lojas

Introdução - O controle consiste em um sistema totalemte voltado para o gerenciamento das ações realizadas na fabrica e nas lojas da empresa, auxiliando no controle de produção, armazenamento, distribuição e vendas dos produtos.

Principais Caracterisiticas e Vantagens:

Controle de usuariso - O sistema téra o controle dos ususarios que utilizarão o Sistema, todo devidamente crotrolados pro setor de acordo com a hierarquia da empresa.As áreas serão liberadas de acordo como o nivel de acesso de casa usuario.

Controle de Espedição - O Sistema tera total controle sobre matéria-primas adquiridas para a produção dos produtos, bem como o controle de armazenamento dos produtos ja prontos para a comercialização.
O administrados terá o total controlesobre a loja onde os produtos ja industrializados serão enviados, bem como analizar os produtos mais vendidos pra o aumento ou não produção do mesmo.

Controle de Estoque - O Sistema terá total controle do estoque, tanto das materia promas necessarias para a prdução dos produtos, bemcomo o controle dos produtos.Com base nessa informação , o Sistema gerará um Catalogo de Fabricantes, como todos ós produtos disponiveis pra venda.

Controle financeiro - Controle financeiro de uma fabrica quanto de uma loja. sistema apresentara relatorios resumidos ou detalhados da movimentação podendo ser filtrado por periodos, lojas , departamentos, produtos, etc.

Contole de Funcionarios- Cada funcionario tem seu cadastro onde é atrelado suas vendas facilitando o calculo da porcentagem vendida e as metas alcançadas. Sendo assim ate mais facil reconhecer os melhores funcionarios

[Seminário] Fatores Humanos na qualidade de software

Nome: Joyce Ra:0850320 Lilian Ra: 180005269

Qualidade
Independente do cliente ou analista, estamos lidando com pessoas;
A qualidade depende das escolhas do cliente que podem ser caracteristicas implicitas ou não implicitas;
A importancia das pessoas, ou seja dos fatores humanos na qualidade esta intimamente ligada com processos de desenvolvimento do software que são extremamente importantes.

Pressão no desenvolvimento do software
A pressão aumenta consideravelmente quando os cronogramas deixam de funcionar e o numero de defeitos encontrados no proejeto tornase incontrolavel.O que pode causar estresse, discussões, e a pressão e combatida com mais pressão).

Horas Extras -levam a insatisfação da equipe , perda de preodutividade e qualidade

Conflitos interpessoais
Dentro de uma equipe de trabalho devemos tomar cuidado com conflitos interpessoais.Onde uma ação de trabalho pode ser vista como uma atitude pessoal.
Um exemplo é p "desenvolvedor X testador".

In stitucionalização dos Processos
A institucionalização deve existir para que evite a criação de uma dependencia sobre o profissional.Ou seja, quando um profissional faz o produto baseado em suas regras, caso este deixe a empresa, gera grande trantorno para a organização.

Planos Realisticos
Uma estrategia muito adotada para ganhar a ocorrencia é propor a concorrencia custos ou prazoa reduzidos.Essa pratica e desleal e desastrosa.As pricipais consequencias são projetos de baixa qualidade- perdendo se a confiaça do cliente, e tambem pressão e estresse no desenvolvimento, perdendo se o espírito do trabalho em equipe.

Revisão do projeto
Encontrar defeitos no proprio trabalho é muito dificil, por isso é recomendado que haja uma visão externa do projeto.Só assim poderá ser encontradp as falhas.É interessante que as revisões sejam executadas de acordo com um procedimento;
Usar listas de verificação, baseados nos problemas encontrados em projetos anteriores;
Sequir um processo estruturado de revisão;crias produtos tendo em mente a futura revisão;

Investimento no Proficional
Deve se investir nos proficionais ao inves de contratar outro. Os prfissionais devem ser respeitaados, ter palestras , treinamentos, congressos e workshops.

Avaliação da equipe de TI
Assim como o profissional deve ser avaliado individualmente, o grupo tambem deve ser avaliado.Onde todos os membros devem estar atentos a todas as situaçõies, sendo elas: condiçoes de trabalho, metas definidas, custo e estrutura de organização.

[ATPS 2] Entrevista

Requisitos Funcionais

• Cadastro de cliente;
• Gerenciar acesso de usuário;
• Controle de estoque;
• Controle de vendas;
• Gerenciar entregas;
• Projeto Intranet;
• Os dados serão armazenados em Datacenter;
• A empresa nunca teve outro sistema antes;
• cerca de 40 usuários iram utilizar o sistema;
• A Performance do sistema deve ser excepcional;
• Deve conter ferramentas atuais;
• O sistema deve gerar os relatórios: Vendas, materiais, logística e brindes;
• O sistema tem que ser fácil, ágil e limpo.

Requisitos não Funcionais

• O sistema deve validar qualquer cadastro em no máximo dois segundos;
• Nem todos os usuários terão acesso a todas as funcionalidades do sistema;
• Todos terão acesso ao controle do estoque, para saber a disponibilidade dos produtos;
• O controle de vendas somente poderá ser acessado pelo gerente do estabelecimento;
• O gerente terá acesso ao controle de entregas para saber se os produtos comprados via internet realmente foram entregues aos respectivos clientes;
• As informações podem ser acessadas através de um sistema de intranet;
• Todas as informações referentes a documentação serão armazenadas no servidos externo, Datacenter, pelo prazo máximo de cinco anos conforme legislação vigente;
• O sistema permite que até 60 usuários fiquem logados ao mesmo tempo, uma vez que 40 usuários utilizam o sistema atualmente, porém esse número pode aumentar, assim como o sistema não poderá operar no limite;
• O sistema gera relatório no fim de todo dia, e também semanal, mensal e anual, referente a todas as vendas, materiais em estoque, entrada e saída de materiais e distribuição de brindes aos clientes
• Essas informações deverão ser acessadas de forma simples, o sistema somente oferece as informações pertinentes aos usuários.

Anderson da Silva RA: 1820000801
Carlos César Pereira Gomes RA: 0850282
Danilo Santos Silva RA: 0850239
Rodrigo Israel da Silva RA: 1803296079

[ATPS 2] Entrevista de requisitos

Requisitos funcionais:

• Cadastro de cliente;
• Restrição de acessos a usuários;
• Cadastro de produtos
• Integração com os fornecedores cadastrados em outro software;
• Controle de estoque;
• Controle de vendas;
• Pagamentos à fornecedores;
• Gerenciamento de entregas;
• Fazer e restaurar backup;
• Relatórios:
- Relatório de clientes que compram mais;
- Relatório de entrada e saída de produtos;
- Relatório de vendas;

Requisitos não funcionais:

• O sistema deverá cadastrar um cliente e enviar uma reposta em no máximo três segundos;
• O sistema deverá cadastrar um produto e enviar uma resposta da ação em no máximo três segundos.
• As informações de estoque da empresa deverá ter disponibilidade em tempo real para todos os usuários.
• O sistema deverá integrar com os fornecedores cadastrados em outro sistema, após estabilização do sistema haverá uma migração desses fornecedores para o este sistema;
• O backup será salvo em um servidor externo (data center), a hospedagem do servidor ficará por conta do cliente.
• O sistema deverá ter uma marcação especial nos produtos para indicar promoção;
• O sistema deverá ser desenvolvido em um linguagem livre;
• O sistema deverá ser desenvolvido em uma linguagem web para ser utilizado inicialmente dentro de uma intranet;
• O sistema deverá ser desenvolvido para funcionar na plataforma windows;
• A empresa terá a sua disposição todo o código fonte do software produzido, inclusive a documentação;
• A empresa terá os principais recursos do software dentro de seis meses;
• O sistema terá disponibilidade para uma média de 40 usuários simultâneos;
• O sistema deverá utilizar o login do windows como login do sistema;

TADS 5
NOME Adenilson B. Oliveira: RA: 0850219
NOME: Carlos E. Momesso RA: 1801252209
NOME: Elica R. Nunes de Oliveira RA: 1801280001
NOME: Roberto G. de Oliveira RA: 1801276381

[Seminário] Prototipação no desenvolvimento de softwares

Prototipação no Desenvolvimento de Softwares
Aprenda a criar protótipos de interfaces com a Ferramenta Axure

Protótipo pode ser considerado um modelo preliminar de um software, ou ainda, uma primeira versão de um produto, podendo ser criticado e aperfeiçoado, buscando obter qualidade no que esta sendo produzido.

O protótipo no desenvolvimento de sistemas
Desenvolver protótipos na elaboração de sistemas é de grande importância para resolução de vários problemas, como por exemplo, diminuir a distancia entre desenvolvedor e usuário, o que facilita alterações nas funcionalidades do sistema, bem como a validação dos requisitos. Outro fator importante é que durante a elaboração do protótipo as intervenções são menos freqüentes, sendo assim, é possível ganhar tempo e conseqüentemente reduzir custos com mão-de-obra. De uma maneira geral os objetivos dos protótipos consistem em validar os requisitos, abordar questões de interface, e avaliar a viabilidade e complexidade do sistema.

Prototipação de Baixa Fidelidade
É utilizado na fase inicial do desenvolvimento como uma maneira de compreender os requisitos e levantar críticas, é elaborado de maneira muito simples, o que não demanda um custo e tempo elevado, porém sua utilidade para no processo de documentação, não podendo servir na fase de codificação, teste de navegabilidade e usabilidade.

Prototipação de Media Fidelidade
Esses protótipos são mais criteriosos e detalhados em relação ao de baixa fidelidade, contendo informações importantes para o usuário e desenvolvedor, com isso exige ferramentas mais especificas. Nesse protótipo o usuário tem uma idéia do que será o seu produto e o desenvolvedor no que se apoiar para a construção do sistema final, porém deverá haver uma avaliação sobre a escolha desse tipo de protótipo para não haver perda de tempo com esse processo e a necessidade de um detalhamento maior do que o mesmo suporta.

Prototipação de Alta Fidelidade
Este tipo de protótipo se assemelha muito ao sistema final, inclusive sua elaboração é com base na mesma tecnologia a ser utilizada no sistema. Um protótipo com mais riquezas de detalhes, e com isso reduz o tempo de desenvolvimento, pois muitos problemas já foram solucionados, bem como permite mensurar precisamente a complexidade e o custo do desenvolvimento. No entanto, não é um método completo e perfeito, pois demanda um custo e tempo elevado em sua elaboração. A prototipação de alta fidelidade, pode ser implementada basicamente com a prototipação Throw-Away e Evolutiva.

Prototipação Throw-Away (Descartável)
Criada com base em uma documentação provisória, com o objetivo de levantar novos requisitos e validar os já implementados, elaborado com ferramentas mais ágeis. Esse processo serve para refinar a documentação e prover qualidade ao produto final, em seguida é descartado, pois o foco parte para o desenvolvimento da aplicação definitiva.
Prototipação Evolutiva
Como o próprio nome diz, consiste em evoluir ate o sistema final, utiliza-se requisitos já compreendidos, porém não há uma documentação definitiva, pois visa reduzir custo e tempo. A interação com o usuário é constante, o que permite ao usuário a visualização precoce do sistema. Além disso, permite vários testes e com isso aumenta a confiabilidade do sistema, sendo assim, o objetivo é fornecer um sistema funcionando. No entanto, esse método pode causar alguns problemas se não for muito bem planejado, pois os sistemas gerados dessa maneira não possuem especificações devidamente documentadas, prejudicando a mensuração de custos, elaborações de contratos e definições do prazo de entrega. Além do mais, pode se tornar difícil manter o sistema.

Wireframes
São documentos elaborados durante a fase de especificação de um projeto Web, consiste em avaliar questões de interface, navegabilidade e usabilidade. O projeto de um Wireframes pode ser considerado um protótipo o que permite se adequar as necessidades do desenvolvedor e do cliente, podendo ser de baixa, media e alta fidelidade. A escolha destes atributos deve ser cuidadosa, pois o projeto pode ficar simples demais ou com muito detalhado, limitando o designer. Além do mais, o usuário deve entende que se trata somente de um “esqueleto” do sistema não gerando expectativas ou má impressão.

Ferramentas de Prototipação
Existem vários softwares para o desenvolvimento de protótipos e wireframes e outros que podem ser utilizados para esse fim, dependendo o grau de detalhamento que se deseja obter, alguns dessas ferramentas são Microsoft Visio, Adobe InDesign, Pencil(com extensão do Firefox) e o Axure RP pro, o qual estaremos entendo um pouco de seu funcionamento.

A Ferramenta de Prototipação Axure
O Axure permite criar diagramas de fluxos do seu protótipo, protótipo wireframes e um documento detalhando os campos existentes na paginas dos protótipos, além de projetos que podem ser compartilhados. Os protótipos do Axure são paginas em HTML, podendo ser usados como base na criação das paginas reais do sistema.

Compartilhando o protótipo
O Axure permite que varias pessoas tenham acesso ao mesmo protótipo, podendo realizar alterações, mantendo toda a equipe do projeto e com acesso a pasta de compartilhamento atualizada e informada. Para realizar o compartilhamento, primeiramente cria-se um repositório selecionando a opção ”New Shared Project”. A primeira tela serve para informar o nome do projeto. Na tela seguinte, informa-se a localização do repositório de compartilhamento do projeto e na ultimo janela informa-se a pasta que será construída o protótipo e pronto o compartilhamento foi realizado.

Conhecendo a Ferramenta
Após aberta a ferramenta, o Axure já inicia com quatro páginas criadas e abas que serão usadas para elaboração dos protótipo, são elas:

• A aba “Sitemap”, contém todas as páginas e diagramas de fluxo referentes ao protótipo.
• A “Widgets” contém as bibliotecas de componentes que são usados para criar os protótipos (Wireframe para paginas) e diagramas de fluxos de páginas (Flow).
• A aba “Masters”, contem fragmentos de páginas que podem ser adicionadas nas telas dos protótipos inúmeras vezes, como o caso de menus e cabeçalhos.
• Na aba “Page Notes & Page Interactions” é possível inserir anotações sobre as páginas ou diagramas de fluxo e habilitar interações para quando a página for acionada.
• A aba “Annotations & Interactions” é onde se fazem as principais configurações, como anotações gerais ou detalhadas e interações dos componentes.

Criando os Protótipos
Primeiramente, foram removidas as páginas já criadas pelo Axure e criadas três novas páginas para melhor exemplificarem o caso de uso na aba ”Sitemap. Nessas paginas na aba “Sitemap”, podem ser definidos:
“Page Notes” uma anotação informando o propósito da página.
Criar tabelas.
Podemos definir as especificações dos componentes das tabelas.
Podemos definir interações entre os componentes.
São definidas numerações para cada especificação.
Podemos criar janela pop-up com suas especificações e interações.
Após definir todas as especificações dos métodos das paginas, pode ser dado inicio a criação do layout da pagina, com os seus devidos campos e botões.
O Axure permite que sejam criadas partes de telas que podem ser utilizadas por mais de uma página, chamadas masters, como o caso de menus, cabeçalhos e rodapés.
O uso de masters é essencial se for necessário reutilizar várias vezes o mesmo pedaço de página em várias outras páginas do sistema como, por exemplo, o uso de menus, que o Axure possui tanto os verticais quanto os horizontais, que podem também ser reaproveitados no sistema real.

Criando o Diagrama de Fluxo
O Axure permite ainda criar os diagramas de fluxo das páginas criadas. Para isso, criamos uma página “Sitemap” chamada de “fluxoPaginas” e modificamos o tipo de página para flow, com o botão direito em Diagram Flow, em seguida arastamos as paginas criadas para dentro do fluxoPaginas e configuramos as condições do fluxo.

Gerando o Protótipo e a Especificação
Para gerar o protótipo, basta selecionar no menu a opção de Prototype ou pressionar F5. Será exibida uma janela para configurações em que se pode configurar com deve ser feita a geração do protótipo.
Quando o protótipo é criado, o Axure cria as páginas e pastas correspondentes às páginas contendo imagens, arquivos CSS e arquivos JavaScript que realizam todas as ações configuradas anteriormente.
Após o protótipo ter sido criado, é aberta uma página contendo uma lista de todas as páginas e diagramas de fluxos, a página selecionada e a descrição dessa página que foi inserida previamente em “Page Notes”.
Para gerar a especificação, aperte F6 ou selecione a opção Specification no menu. O Axure irá gerar um documento no formato padrão Word, com todas as informações existentes, podendo ser utilizados outros editores de texto.

Conclusão
Através dos conceitos mencionado no texto podemos entender um pouco melhor o assunto sobre prototipação, bem como ,conhecer a ferramenta Axure, utilizada do desenvolvimento de protótipos.

[Seminário] Boas Práticas na Engenharia de Requisitos

Engenharia de Requisitos

• 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 pode ser vista como uma sub-área da Engenharia de Software, cujo principal objetivo é a obtenção de uma especificação correta e completa dos requisitos.

Objetivo

• O principal objetivo da engenharia de Requisitos é criar e manter documentos de requisitos de sistemas, chamado de documento de Especificação de Requisitos de software (DERS).
• O processo de engenharia de requisitos, contém quatro grandes sub-processos que são:
-Estudo de viabilidade
-Elicitação e análise
-Especificação
-Validação

Ciclo de Vida Clássico

Definição:

• É um método sistemático e seqüencial, em que o resultado de uma fase se constitui na entrada da outra fase.
• Foi modelado de acordo com o ciclo da engenharia convencional e abrange as seguintes fases:
- Análise de Requisitos do software
- Projeto
- Implementação ou Codificação
- Testes
- Manutenção

• Análise de Requisitos de Software: Constitui a modelagem lógica do
sistema. Nessa fase, os requisitos levantados são transformados em modelos os quais representam o sistema em nível conceitual.

• Projeto: Nessa fase, os modelos conceituais são transformados em modelos físicos, os quais devem estar mais próximos da implementação.

• Implementação ou codificação: Tradução do projeto em uma forma que seja legível pela máquina.

• Testes: Os testes são realizados após a implementação. Os testes são feitos internamente a um módulo, linha a linha, e também são feitos testes de integração dos módulos.

• Manutenção/Suporte: A fase de manutenção pode ser:

- Corretiva: Erros podem ser encontrados durante o funcionamento do sistema.

Documento de Especificação de Requisitos de Software

• O DERS, segundo o IEEE (Institute of Electrical and Electronics Engineers), deve ser completo e não ambíguo, sendo responsável por auxiliar os clientes de software a descrever com precisão o que eles desejam obter, e desenvolvedores de software a entender exatamente o que o cliente deseja. Segundo o IEEE, um bom DERS deve prover diversos benefícios, tais como:

- Estabelecer a base de acordo entre os clientes e a empresa fornecedora sobre o que o software irá fazer.
- Reduzir o esforço de desenvolvimento.
- Prover uma base para estimativas de custos e prazos.
- Prover uma base para validação e verificação do produto.
- Facilitar a manutenção do produto de software final.

• Um DERS conta com alguns padrões indicados para sua elaboração com práticas recomendadas para especificação de requisitos de software, segundo essas práticas o DERS deve ter uma estrutura da seguinte forma:

- Propósito: Deve delinear o propósito particular deste DERS e especificar para quem está sendo feito esse documento.

- Escopo: Deve especificar o produto software a ser produzido, nomeando-o, explicar o que o produto irá fazer e, se necessário, o que não irá fazer, descrever as aplicações do software que está sendo especificado, incluindo benefícios, objetivos e metas relevantes.

- Definições, siglas e abreviaturas: Deve prover a definição de todos os termos, siglas e abreviaturas que são necessárias para entender este DERS.

- Referencias: Deve prover uma lista de todos os documentos que forem referenciados em outros locais do DERS, identificando cada um por autor, titulo, data, editora, organização, e outros atributos quando aplicáveis.

- Visão Global: Deve apresentar de forma sucinta e resumida o que os capítulos restantes do DERS irão tratar.

- Perspectiva do produto: Deve colocar o produto na perspectiva de outros produtos relacionados. Se é um produto independente, isso deve ser dito na hora. Caso contrario, se é um componente de um sistema maior, o que ocorre freqüentemente, então esta subseção deve relatar as interfaces entre esse software e o sistema, alem dos requisitos do sistema maior para a funcionalidade deste software.

- Funções do produto: Deve prover um índice das principais funções que o software irá executar.
- Características do Usuário: Deve descrever as características gerais do usuário do produto.

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

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

- 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.

• Com essa analise, podemos facilmente detectar que boas praticas de engenharia de requisitos que procurem evitar a propagação de falhas para outras fases podem trazer benefícios como a redução de custo do projeto. Entre as boas práticas estão a padronização, a inspeção e a revisão do DERS.

- Requisitos Específicos: Descreve os requisitos de software que serão funcionais e não-funcionais.

- Requisitos Funcionais: São aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o sistema deve dispor.

- Requisitos não-funcionais: são aqueles que expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, desempenho, robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentados restrições e especificações de uso para os requisitos funcionais.

• Diagrama de Casos de Uso

- O diagrama de casos de uso deve mostrar, graficamente, todas as funções que um sistema precisará desempenhar e, para sua construção, deve obedecer aos padrões da UML (Unified Modeling Language).

• 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.

1. A 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.

2. Construção do DERS

• A seguir segue alguns exemplos referentes ao DERS:

Exemplo da descrição do caso de uso “Cadastrar Veículos”.

Exemplo 1

Nome do Caso de uso: Cadastrar Veículos
Descrição: O Diretor ou gerente solicita o cadastro de veículos liberados para locação, o funcionário faz o cadastro e libera o veículo para a disponibilidade de locação.
Atores Diretor/Gerente/Funcionário
Interessados: Empresa
Pré-Requisito: Usuário deve estar logado no sistema
Interação entre ator e sistema:
Ator Sistema
1. Usuário informa os dados do veículo a ser cadastrado.
2. O sistema exibe as informações a serem cadastradas.
3. Usuário verifica as informações e confirma;
4. O sistema salva as informações e exibe uma mensagem de sucesso no cadastro;

Fluxo Principal:
1. [EV] O usuário informa os dados do veículo a ser cadastrado;
2. [RS] O sistema exibe as informações a serem cadastradas;
3. [EV] Usuário verifica as informações confirmando-as;
4. [RS] O sistema armazena/exibindo uma mensagem de sucesso na operação;
Exceções:
1. Veículo cadastrado.
1.1. [EV] Usuário informa os dados do veículo a ser cadastrado;
1.2. [RS] O sistema exibe uma mensagem de veículo já cadastrado;
2. Veículo não cadastrado.
1.1 volta ao fluxo principal passo 1.

Exemplo do diagrama de casos de uso.

Exemplo 2





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 de Boas Práticas de Engenharia de Software
Grupo:
Carlos Eduardo Momesso Raiz, RA:1801252209
Élica Regina de Oliveira, RA: 1801280001

[SEMINÁRIO] Requisitos Não Funcionais

Introdução

Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou não.

Requisitos Não Funcionais e Arquitetura de Software
O projeto de arquitetura de software tem um papel essencial em sistemas de grande porte e complexos. A arquitetura de software é fundamental para a produção de sistemas onde se tem um conjunto de funcionalidades. Entretanto anterior a fase de projeto há a necessidade de fazer o levantamento de requisitos.
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 deveria ser implementado.
Durante a fase de levantamento de requisitos um arquiteto de software faz uso da sua experiência a fim de levantar características do sistemas a ser desenvolvido. Contudo há ainda outros recursos a serem usados pelo projestita, como a construção de cenários, que auxiliam tanto na elicitação de requisitos como na analise dos mesmos. É importante observar que o uso de cenários de e uma re-análise do requisitos é útil para refinar a arquitetura que será empregada no sistema a ser desenvolvido.
De posse desses requisitos o arquiteto de software pode então buscar e identificar qual o melhor estilo ou combinação destes oferece o suporte mais adequado a esses requisitos.
Vale ressaltar que a complexidade de um software é determinada tanto pelos seus requisitos funcionais – o que ele faz – e seus requisitos não funcionais – como ele faz.
Na Engenharia de Sistemas de Software são aqueles que descrevem não o que o sistema fará, mas sim como ele fará. Como por exemplo requisitos de desempenho, requisitos da interface externa do sistema restrições de projeto e atributos de qualidade.
Os requisitos são avaliados, em parte, por meio de testes e em outras partes é avaliado de maneira subjetiva.
Os requisitos não funcionais são de suma importância no desenvolvimento de um software, esses requisitos também são chamados de atributos de qualidade e tem papael relevante no desenvolvimento de um sistema atuando como critério de seleção e/ou composição de uma arquitetura de software.

Requisitos Não Funcionais
O requisitos não funcionais não estão diretamente relacionados às funcionalidades do sistema, mas sim relacionados a um processo de qualidade do sistema a ser desenvolvido, podendo ser usados como critério de seleção na escolha de alternativas de projeto, estilo arquitetural e implementação. Desconsiderar tais requisitos é dispendioso, pois torna a correção difícil uma vez que o sistema tenha sido implantado.
Os requisitos abordam um aspecto de qualidade. Se tais requisitos não forem levados em consideração, então o sistema poderá ser inconsistente e de baixa qualidade.
Ao se desenvolver um novo sistema, os projetistas apresentam um conjunto de atributos de qualidade ou requisitos não funcionais que o sistema deveria suportar, como por exemplo requisitos de desempenho, portabilidade, manutenibilidade e escaliabilidade. É importante lembrar que cada estilo arquitetural suporta requisitos não funcionais especifícos. A estruturação e um fator determinante no suporte à esses requisitos. Por exemplo o uso de camadas para separar funcionalidades torna o sistema modular e facilita sua manutenção.
O padrão IEEE-Std 830 [IEEE 1993] (http://www.scribd.com/doc/453557/ieee830Traducao) lista um conjunto de 13 requisitos não funcionais a serem considerados no desenvolvimento de um software. O Padrão inclui, desempenho, confiabilidade, portabilidade e segurança, dentre outros.
Em, [Sommerville 2007] é apresentado um conjunto de 7 requisitos não funcionais, sendo alguns destes ainda decompostos, como mostra a figura abaixo:



Usabilidade
É um atributo de qualidade de qualquer sistema interativo, no qual ocorre interação entre sistema e seres humanos. A noção de usabilidade vem do fato de que qualquer sistema que é utilizado por pessoas seja fácil de aprender e fácil de usar. Requisitos de usabilidade especificam tanto o nível de desempenho quanto o nível de satisfação do usuário do sistema.
Dessa forma a usabilidade por ser expressa em:
• Facilidade de aprender – associado ao tempo e esforço mínimo exigido para alcançar 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 o sistema;
A usabilidade é um dos atributos de qualidade que tem sido cada vez mais levada em consideração durante o desenvolvimento de um software, já que ela pode ser afetada pelos componentes funcionais (ou de aplicação). Mesmo que esses componentes sejam bem projetados a usabilidade ainda assim poderá ser comprometida se a arquitetura do sistema não levar em consideração a facilidade de efetuar uma modificação.

Manutenibilidade
É o termo empregado quando nos referimos às modificações no software após ele ter sido disponibilizado para uso. Na verdade o termo manutenibilidade é bem abrangente já que envolve tanto a parte de reparos (bugs) como também a parte de evolução do sistema(upgrade).
A capacidade de efetuar um reparo depende do número de componentes do sistema. Um sistema monolítico, ou seja, que é construído com um componente só torna se mais difícil de ser reparado quando é de grande porte. Já em um sistema modularizado esse tipo de reparo tende a ser mais fácil, já que o erro fica confinado a uns poucos módulos e com funcionalidades adequadamente separadas.
De um modo geral a manutenibilidade é um dos requisitos mais relacionados com a arquitetura do software, assim também como a facilidade de fazer alteração no sistema, seja adicionando ou modificando alguma funcionalidade sem que esta comprometa o desempenho atual do sistema em funcionamento.

Confiabilidade
Confiabilidade de software é a probabilidade de o software não causar uma falha no sistema durante um determinado período de tempo sob condições especificadas. Em outras palavras é o tempo médio em que o sistema trabalhará de forma desejada até apresentar algum tipo de erro.
Para avaliar a confiabilidade um sistema utiliza-se os seguintes critérios:
• Disponibilidade - É o quão o sistema está disponível para uso. Ex: para cada 1000 solicitações ao software, 999 serão atendidas;
• Taxa de ocorrência de falha - É o período de tempo no qual um comportamento inesperado acontece quando observado. Ex: 2/1000;
• Probabilidade de falha durante a fase operacional - É a probabilidade de falhas que um sistema pode ocasionar quando estiver em operação;
• Tempo médio até a ocorrência de falha ou Mean Time To Failure: É o indicativo de quanto tempo o sistema permanecerá operacional antes que uma falha aconteça.

Desempenho
Desempenho é um dos mais importantes requisitos não funcionais, porém ele está diretamente ligado a conflitos entre outros requisitos não funcionais, como por exemplo, a usabilidade, se um sistema de software é lento ele pode reduzir a produtividade dos funcionários fazendo com ele não atenda a necessidade proposta. Se o sistema exige muita memória ou ocupa muito espaço no HD, a execução de outros programas pode ser comprometida.
Ao desenvolver um sistema de software é necessário avaliar:
• Tempo de resposta: É o tempo em que o usuário realiza uma operação e tem o retorno disso. Ex: Quando inserimos um cartão no caixa eletrônico, é recomendável que o sistema exiba uma nova janela de operações após alguns segundo.
• Requisitos de processamento (throughput) - Representa a quantidade de dados que o sistema deveria processar em um determinado período de tempo.
• Requisitos de temporização - Especifica o quão rapidamente o sistema coletará dados e como fará para sobrescrever os dados anteriores.
• Requisitos de espaço- Em alguns casos os requisitos de espaço podem ser considerados já que estão diretamente relacionadas à execução de um sistema.

Portabilidade
Portabilidade pode ser definido como a facilidade na qual o software pode ser transferido de um sistema computacional para outro. De modo geral refere-se à habilidade do sistema de ser executado em diferentes plataformas. Com as constantes mudanças entre custos de software e hardware torna-se cada vez mais importante a avaliação de portabilidade dentro de um projeto de software, com isso além de diminuir custos ao aderir a uma nova tecnologia de desenvolvimento, o processo de transferência para outra plataforma ocorre de forma mais segura.

Reusabilidade
Com o crescente intuito de maximizar os lucros e diminuir o tempo de desenvolvimento, a reusabilidade tem sido muito utilizada. Ao invés de começar um sistema do zero, pode-se fazer o uso de projetos existentes a fim de reutilizar componentes já desenvolvidos, objetivando minimizar esforços e buscar um elevado índice de qualidade já que os recursos utilizados já foram devidamente testados e validados. Quase tudo pode ser reaproveitado dentro de um sistema, desde que o mesmo já tenha sido produzido com este intuito.

Segurança
Este requisito não funcional implica na construção de um sistema de forma que o mesmo possua restrições a usuários não autorizados e dados sigilosos. Dessa forma, a segurança é vista como a probabilidade de qualquer tipo de ameaça seja repelida. É Impossível afirmar que um sistema é cem por cento seguro, conforme as tecnologias avançam, novos métodos de invasão são descobertos, fazendo com que a segurança de um software seja por diversas vezes reavaliada. Algumas práticas ajudam na prevenção da quebra da segurança como, por exemplo:
Apenas usuários com permissões autenticadas por um componente de autenticação poderão visualizar informações confidencias;
• Permissões de acessos aos usuários somente podem ser alteradas por administradores do sistema;
• Backups do sistema devem ser feitos periodicamente, de preferência em máquinas diferentes da qual o sistema está em uso;
• Todas as informações transmitidas entre o servidor de dados e os clientes devem estar criptografadas;
• Impedir que atualizações do sistema ou liberações de acessos sejam feitas de forma não autorizada;
• Limitar o tempo de acesso ao sistema pelo usuário, a fim de reduzir qualquer tipo de acesso;
• Logs de realizações de eventos no sistema, com isso identificar qual usuário realizou determinado processo;
• Detecção de invasores a fim de alarmar os administradores do sistema;
• Simulações de invasão;
• Antivírus atualizado;

Conclusão
A elicitação de requisitos funcionais e não funcionais, é uma etapa fundamental no desenvolvimento de sistemas de software. Aliado a isso, a experiência do arquiteto de software é de grande importância. Como saída tem-se um conjunto de requisitos funcionais dando suporte as funcionalidades do sistema e um conjunto de requisitos não funcionais dando suporte a arquitetura do software.

Seminário de Requisitos Não Funcionais

Grupo:Roberto G. de Oliveira, RA 1801276381
Adenilson B. Oliveira, RA 0850219