Teste meu site no Netsparker para saber as vunerabilidades – veja os resultados

 

Relatório do Netsparker – Community Edition

Portfólio – Promoção com API do Google Maps

Promoção desenvolvida com api do google maps, Php5 e Mysql5.

Prazo: 2 semanas.

Funcionalidades: Adaptação da api do google maps para suportar as funcionalidades da promoção que podem ser compreendidas a partir do vídeo:

Vídeo-tutorial:

Vídeo-Case:

Layout da Home da Promoção:

Portfólio – Portal de Relacionamento para Família

Portal de relacionamento para uma determinada família brasileira.

Desenvolvimento: PHP5/Mysql5

Prazo: 3 meses

Funcionalidades: Gerenciamento de usuários, gerenciamento de notícias com fotos e comentários, gerenciamento de galeria de fotos e vídeos, calendário dinâmico, gerenciador de newsletter, gerenciador administrativo completo de todo conteúdo do site, chat entre usuários online na página, mensageiro que envia contato por e-mail, … dentro outras inúmeras funcionalidades.

Critério de Qualidade

qualidade de processo

qualidade de software ( iso/iec 9126 – 1, McCall )

• iso certifica software, não produto.
• exemplo: requisitos de qualidade interna: códicos legiveis, …
• quem certifica a qualidade de software é a equipe de teste.

 

Qualidade do produto e o ciclo de vida do software 

As visões de qualidade interna, qualidade externa e qualidade em uso mudam durante o ciclo de vida do software.
Por exemplo, a qualidade especificada como requisito no início do ciclo de vida é uma visão, principalmente, do ponto de
vista de qualidade externa e do usuário, e difere da qualidade do produto intermediário, tal como a qualidade na fase de
projeto, que é uma visão, principalmente, do ponto de vista de qualidade interna e do desenvolvedor. As tecnologias
utilizadas para atingir o nível de qualidade necessário, como especificação e avaliação de qualidade, precisam apoiar estes
diversos pontos de vista. É necessário definir estas perspectivas de qualidade e suas tecnologias associadas, a fim de que
a qualidade seja gerenciada de modo apropriado em cada estágio do ciclo de vida.

 

 

 

 

 

 

 

 

 Modelo de qualidade para qualidade externa e interna

Esta seção define o modelo de qualidade externa e interna. Ele categoriza os atributos de qualidade de software em seis
características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade) as quais são, por
sua vez, subdivididas em subcaracterísticas (figura 4). As subcaracterísticas podem ser medidas por meio de métricas
externas e internas.

 

Estou estudando alguns Frameworks

No desenvolvimento do software, um framework ou arcabouço é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de software.Frameworks são projetados com a intenção de facilitar o desenvolvimento de software, habilitando designers e programadores a gastarem mais tempo determinando as exigências do software do que com detalhes de baixo nível do sistema.

Origem: Wikipédia, a enciclopédia livre.

Akelos

Nível: Alto

Pontos Positivos: robusta, segura, material de fácil acesso, muito utilizada, usabilidade boa.

Pontos Negativos: pouco conteúdo em português.

B2 Evolution

Nível: Baixo

Pontos Positivos: poderosa para blogs.

Pontos Negativos: poucas funcionalidades para sistema, pouquíssima material.

CakePHP

Nível: Alto

Pontos Positivos: Robusta, segura, muito conteúdo na Internet, muito fácil e pratico a usabilidade.

Pontos Negativos:

CodeIgniter

Nível: Médio

Pontos Positivos: Ferramenta muito prática, muito poderosa, com bastante referencia, muito leve.

Pontos Negativos: Não é robusta, pode não ser tão segura, pode acabar sendo inflexível para determinadas funcionalidades.

Miolo

Nível: Médio

Pontos Positivos: Robusta, prática, tem uma comunidade brasileira que disponibiliza muita informação.

Pontos Negativos: Pouca documentação na internet.

Prado

Nível: Médio

Pontos Positivos:

Pontos Negativos: Poucas referências e pouquíssimo conteúdo em português

segundo o site http://www.phpframeworks.com:

Top 5 PHP Frameworks

1 Akelos (avg: 4.3)   discuss Akelos at forum

Ranking:

2 PHPDevShell (avg: 4.3)

Ranking:

3 CodeIgniter (avg: 4.3)   discuss CodeIgniter at forum

Ranking:

4 Symfony Project (avg: 4.2)   discuss Symfony Project at forum

Ranking:

5 Prado (avg: 4.1)   discuss Prado at forum

Ranking:

ENGENHARIA DE SOFTWARE – Requisitos de software

“The hardest single part of building a software system is deciding what to build…No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Segundo Frederick P. Brooks Jr. a requisito é:1. uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo;

2. uma condição ou capacidade que deve estar presente num sistema para satisfazer um contrato, padrão, especificação ou outro documento formal;
3. uma representação documentada de uma condição ou capacidade como em (1) e (2).

“Requisito é uma função, restrição ou outra propriedade que precisa ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do futuro sistema”

[Abbott 86]Desde que a Especificação de Requisitos de Software (ERS) tem um papel específico no processo do desenvolvimento do software, o autor da ERS deve ter cuidado para não ir além dos limites desse papel. Isto significa que a ERS [IEEE 98]:

a) Deve corretamente definir todos os requisitos do software. Um requisito do software pode existir por causa da natureza da tarefa a ser resolvida ou por causa de uma característica especial do projeto.

b) Não descreve todos os detalhes do projeto ou da execução. Estes devem ser descritos na fase de projeto.

c) Não impõe restrições adicionais no software. Estas são apropriadamente especificadas em outros documentos, como no Plano de Garantia de Qualidade do software.

Padrões para Especificação de Requisitos – IEEE 830 Recommended Practice for Software Requirements Specifications- IEEE 1233 Guide for Developing System Requirements Specifications – IEEE 610 Standard Glossary of Software Engineering Terminology:

1. Critérios de Qualidade de uma ERS:

Segundo a IEEE, uma boa Especificação de Requisitos de Software deverá ser [IEEE 98]:

a) Correta Correct	Uma Especificação de Requisitos de Software está correta se e somente se todo requisito indicado nela é um requisito que o software deverá possuir.
b) Não-ambigua Unambiguous	Uma ERS é não-ambígua se, e somente se, cada exigência indicada nela tem somente uma interpretação. No mínimo, isto requer que cada característica do produto final esteja descrita usando um único termo original.
c) CompletaComplete	Uma ERS está completa se, e somente se, inclui os seguintes elementos: a) Todas as exigências significativas, relacionadas à funcionalidade, desempenho, restrições, atributos, ou às interfaces externas. b) Definição das respostas do software a todas as classes realizáveis de dados de entrada em todas as classes realizáveis de situações. c) Rótulos e referências completas a todas as figuras, tabelas, e diagramas na ERS e a definição de todos os termos e unidades de medida.
d) ConsistenteConsistent	Uma ERS é internamente consistente se, e somente se, nenhum subconjunto dos requisitos individuais descritos nela conflitar.
e) PriorizávelRanked	Uma ERS é priorizável por importância e/ou estabilidade se cada requisito descrito nela tiver um identificador para indicar a importância ou a estabilidade daquele requisito em particular.
f) VerificávelVerifiable	Uma ERS é verificável se, e somente se, cada requisito indicado nesta é verificável. Um requisito é verificável se, e somente se, existe algum processo efetivo de custo finito com que uma pessoa ou uma máquina podem se certificar de que o produto de software se encontre com a exigência.
g) ModificávelModifiable	Um ERS é modificável se, e somente se, sua estrutura e estilo são tais que todas as mudanças às exigências podem ser feitas facilmente, completamente, e consistentemente.
h) RastreávelTraceable	Uma ERS é rastreável se a origem de cada um de seus requisitos estiver clara e facilitar a referência de cada requisito em futuros desenvolvimentos ou seu destaque na documentação.

Os três tipos de conflitos prováveis em uma ERS são:a) As características especificadas de objetos do mundo real podem conflitar, por exemplo, i) o formato de um relatório de saída pode ser descrito em uma exigência tabular mas em outra como textual. ii) um requisito pode indicar que todas as luzes serão verdes quando outro pode indicar que todas as luzes serão azuis. b) Pode haver conflitos lógico ou temporal entre duas ações especificadas. Por exemplo, i) Um requisito pode especificar que o programa adicionará duas entradas e outro pode especificar que o programa as multiplicará. ii) uma exigência pode indicar que “A” deve sempre seguir “B”, quando outro pode requerer que “A” e “B” ocorram simultaneamente. Duas ou mais exigências podem descrever o mesmo objeto do mundo real, mas usar termos diferentes para esse objeto. Uma maneira de priorizar exigências é distinguir classes das exigências como essencial, condicional, e opcional.

a) Essencial. Implica que o software não será aceitável a menos que estas exigências sejam fornecidas da maneira combinada.

b) Condicional. Implica que são exigências que realçariam o software, mas não o fariam inaceitável se estiverem ausentes.

c) Opcional. Implica uma classe das funções que podem ou não podem ser de valor. Isto dá ao fornecedor a oportunidade de propor algo que excede a ERS.Em geral, qualquer requisito ambíguo é não-verificável.

Os requisitos não-verificáveis incluem indicações tais como de “funcionar bem”, “boa interface humana”, e “geralmente deverá acontecer”. Estes requisitos não podem ser verificados porque é impossível definir os termos “geralmente”, “bem” ou “bom”. A indicação de que “o programa nunca incorporará um laço infinito” é não-verificável, porque testar esta qualidade é teoricamente impossível.Um exemplo de uma indicação verificável é “A saída do programa deverá ser produzida dentro de 20s em 60% do tempo; e dentro de 30s em 100% do tempo.”Esta indicação pode ser verificada porque usa termos concretos e quantidades mensuráveis. Modificabilidade requer que geralmente uma ERS :

a) Tenha uma organização coerente e fácil de usar, com tabela de conteúdos, um índice e referências cruzadas explícitas;

b) Não seja redundante (isto é, o mesmo requisito não deve aparecer em mais de um lugar na ERS);
c) Expresse cada requisito separadamente. Os seguintes dois tipos de rastreabilidade são recomendados:
d) Rastreabilidade para trás (Backward traceability) (isto é, aos estágios anteriores do desenvolvimento). Isto depende que cada requisito possua explicitada a relação com sua origem, em documentos anteriores;e)
Rastreabilidade para frente (Forward traceability) (isto é, a todos os originais gerados pela ERS). Isto depende que cada requisito possua um único nome ou número de referência.

2. Problemas da Especificação de Requisitos

Em 1994, o Standish Group pesquisou mais de 350 empresas sobre os seus mais de 8000 projetos de software, para descobrir como eles estavam se saindo. Os resultados são esclarecedores. Trinta e um por cento dos projetos de software foram cancelados antes de serem concluídos. Além disso, em grandes empresas, somente nove por cento dos projetos foram entregues dentro do prazo e do valor estimado para o orçamento, e 16 por cento satisfizeram estes critérios nas pequenas empresas. [Pfleeger 2004]

Para entender o porquê disso, Standish pediu aos entrevistados para explicarem as causas de os projetos terem falha­do. Os fatores principais são relatados a seguir

1. requisitos incompletos (13,1%)

2. falta de envolvimento por parte do usuário (12,4%)

3. falta de recursos (10,6%)

4. expectativas não realistas (9,9%)

5. falta de apoio dos executivos (9,3%)

6. modificações nos requisitos e nas especificações (8,7%)

7. falta de planejamento (8,1%) 8. o sistema não era mais necessário (7,5%) Fonte: Standish Group, 1994

Observe que algumas partes do processo de identificação, definição e gerenciamento de requisitos estão envolvidos em quase todas essas causas. A falta de cuidado com o entendimento, a documentação e o gerenciamento dos requisitos podem levar a uma grande quantidade de problemas: a construção de um sistema que resolve o problema errado, que não funciona como esperado, ou que é difícil para os usuários entenderem e utilizarem. Além disso, um processo de requisitos ineficiente pode custar caro. Boehm e Papaccio relataram que, se custa US$1,00 identificar e resolver um problema referente aos requisitos durante o processo de definição de requisitos, essa identificação e solução poderão custar US$5,00 durante o projeto; US$10,00 durante a codificação, US$20,00 durante o teste de unidades e US$200,00, depois que o sistema tiver sido entregue! Assim, vale a pena utilizar algum tempo para entender o problema e seu contexto, e obter os requisitos certos na primeira vez.

 

3. TIPOS DE REQUISITOS

Os documentos de definição e especificação de requisitos descrevem tudo sobre como o sistema interagirá com seu ambiente. Eles incluem os seguintes tipos de itens:

a) Ambiente físico:

Onde o equipamento funcionará?

Esse funcionamento se dará em um ou em vários locais?

Existe alguma restrição ambiental, tal como temperatura, umidade ou interferência magnética?

b) lnterfaces:

A entrada tem origem em outro ou outros sistemas?

A saida vai para outro ou outros sistemas?

Existe uma maneira preestabelecida pela qual os dados devem ser formatados?

Existe alguma mídia definida, que os dados devem utilizar?

c) Os usuários e os fatores humanos:

Quem utilizará o sistema?

Haverá diversos tipos de usuários?

Qual o nível de habilidade de cada tipo de usuário?

Que tipo de treinamento será necessário para cada tipo de usuário?

Que facilidade o usuário terá para entender e utilizar o sistema?

Qual será a dificuldade para que o usuário utilize inadequadamente o sistema?

d) Funcionalidade:

O que o sistema realizará?

Quando o sistema o fará?

Existem diversos modos de operação?

Como e quando o sistema pode ser modificado ou aprimorado?

Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou à saída?

e) Documentação:

Que documentação é necessária?

Essa documentação deve ser on-line, no formato de livro, ou ambos?

A que público se destina cada tipo de documentação?

f) Dados:

Qual deverá ser o formato dos dados de entrada e saída?

Com que freqüência eles serão enviados ou recebidos?

Que precisão devem ter?

Com que grau de precisão os cálculos devem ser feitos?

Qual será o fluxo de dados do sistema?

Existem dados que devem ser mantidos por algum tempo?

g) Recursos:

Que materiais, pessoal ou outros recursos são necessários para construir, utilizar e manter o sistema?

Que habilidades os desenvolvedores devem ter?

Quanto espaço físico será ocupado pelo sistema?

Quais são os requisitos quanto à energia, ao aquecimento ou condicionamento de ar?

Existe um cronograma definido para o desenvolvimento?

Existe um limite de custo para o desenvolvimento ou para a aquisição de hardware ou de software?

h) Segurança:

O acesso ao sistema ou às informações deve ser controlado?

Como os dados de um usuário serão isolados dos de outros usuários?

Como os programas dos usuários serão isolados de outros programas e do sistema operacional?

Com que freqüência será feito o backup (cópia de segurança) do sistema?

As cópias de segurança (backup) devem ser armazenadas em um local diferente?

Devem ser tomadas precauções contra fogo. danos provocados pela água, ou ocorrência de roubo?

i) Garantia da Qualidade:

Quais são os requisitos quanto à confiabilidade, disponibilidade. manutenibilidade, segurança e os outros atributos de qualidade?

Como as características do sistema devem ser demonstradas para os outros?

O sistema deve detectar e isolar defeitos?

Qual é o tempo médio entre falhas, que foi determinado?

Existe um tempo máximo permitido para reinicializar o sistema, depois de uma falha?

Como o sistema pode incorporar modificações no projeto?

A manutenção meramente corrigirá os erros ou também incluirá o aprimoramento do sistema?

Que medidas de eficiência serão aplicadas à utilização dos recursos e ao tempo de resposta?

Com que facilidade o sistema se deslocará de um local para outro, ou de um tipo de computador para outro?

Requisitos funcionais e não-funcionais

Em particular, os requisitos descrevem atividades do sistema, tais como uma reação à inserção de dados, e o estado de cada entidade antes e depois de a atividade ocorrer. Por exemplo, em um sistema de folha de pagamento, os funcionários podem existir em pelo menos dois estados: funcionários que ainda não foram e funcionários que já foram pagos. Os requisitos descrevem como, na emissão dos contracheques, um funcionário pode se ‘mover’ do primeiro estado para o segundo. Para nos ajudar a descrever os requisitos, podemos classificá-los de duas maneiras: funcionais e não-funcionais. Um requisito funcional descreve uma interação entre o sistema e seu ambiente. Por exemplo, para se determinar os requisitos funcionais, decidimos quais estados são aceitáveis para o sistema. Além disso, os requisitos funcionais descrevem como o sistema deve se comportar, considerando um certo estímulo. Por exemplo, para um sistema de impressão semanal de contracheques, os requisitos funcionais devem responder às questões sobre quando os contracheques são emitidos. Qual informação é necessária para que um contracheque seja emitido?
Sob quais condições o valor do pagamento pode ser modificado?
O que causa a exclusão de um funcionário da folha de paga­mento?
Podemos utilizar várias técnicas para determinar os requisitos funcionais, incluindo os casos de uso.Em vez de informar o que o sistema fará, os requisitos não‑funcionais colocam restrições no sistema. Isto é, os requisitos não-funcionais ou restrições descrevem uma restrição no sistema que limita nossas opções para criar uma solução para o problema. Por exemplo, podemos receber a informação de que o sistema deverá ser desenvolvido em um computador Aardvark ou de que os contracheques devem ser distribuídos para os funcionários em não mais do que quatro horas depois de os dados iniciais terem sido lidos. De maneira semelhante, podemos receber a orientação de que as consultas ao sistema devem ser respondidas em menos de três segundos.

4. Documento de Requisitos [Pfleeger 04]

Segundo Shari Pfleeger, um documento de requisitos deve conter os seguintes tópicos:

1. Introdução

2. Propósito: objetivo da ER, audiência

3. Escopo: produto, área, objetivos (superficial, introdutório)

4. Definições, siglas e abreviaturas

5. Referências (a outros documentos)

6. Overview (como está estruturado o documento)

7. Descrição Geral

8. Perspectiva do produto: auto-contido, parte de outro

9. Funções do produto (sem detalhes)

10. Características do usuário

11. Estimativas de carga de trabalho (ex: transações por dia)

12. Ambiente Operacional (HW, SW, comunicações)

13. Restrições gerais

14. Dependências

15. Requisitos Específicos

16. Funcionais: usar uma única frase e um identificador

17. Interface externa (HW, SW, comunicação, usuários)

18. Desempenho: mensuráveis

19. Restrições de projeto

20. Não-funcionais

Já Wilson de Pádua Paula Filho [Paula Filho 03], propõe o seguinte conteúdo para um documento de requisitos:

1. Introdução
1.1. Objetivos deste documento
1.2. Escopo do produto
1.2.1. Nome do produto e de seus componentes principais
1.2.2. Missão do produto
1.2.3. Limites do produto
1.2.4. Benefícios do produto
1.3. Materiais de referência
1.4. Definições e siglas
1.5. Visão geral deste documento

2. Descrição geral do produto
2.1. Perspectiva do produto
2.1.1. Diagrama de contexto
2.1.2. Interfaces de usuário
2.1.3. Interfaces de hardware
2.1.4. Interface de software
2.1.5. Interfaces de comunicação
2.1.6. Restrições de memória
2.1.7. Modos de operação
2.1.8. Requisitos de adaptação ao ambiente
2.2. Funções do produto
2.3. Usuários e sistemas externos
2.3.1. Descrição
2.3.2. Características dos usuários
2.4. Restrições
2.5. Hipóteses de trabalho
2.6. Requisitos adiados

3. Requisitos específicos
3.1. Requisitos de interface externa
3.1.1. Interfaces de usuário
3.1.2. Interfaces de hardware
3.1.3. Interfaces de software
3.1.4. Interfaces de comunicação
3.2. Requisitos funcionais
3.2.1. Diagramas de casos de uso
3.2.2. Casos de uso
3.3. Requisitos não funcionais
3.3.1. Requisitos de desempenho
3.3.2. Requisitos de dados persistentes
3.3.3. Restrições ao desenho
3.3.4. Atributos da qualidade

5. Métodos de Especificação de requisitos

5.1 REUNIÕES

Antes:
1. preparar o ambiente (luzes, ruídos, cadeiras confortáveis, lugar sem interrupções, temperatura, forma de apresentação)
2. marcar com antecedência (verificar disponibilidade de horários)
3. marcar horário de início e de fim previsto
4. preparar a pauta e distribuir com antecedência, dizendo que assuntos serão tratados
5. Ao começar a reunião:
6. expor a finalidade e os resultados esperados (decisões a serem tomadas, posições)
7. rever a ata da reunião passada (decisões que foram tomadas) e verificar se as metas foram atingidas
8. apresentar as pessoas dizendo sua função na reunião

Ao ouvir:
1. parar de falar
2. facilitar o falante a falar, fazer perguntas
3. mostrar interesse, que se quer ouvir
4. remover distrações5. simpatizar com o falante
6. ser paciente
7. ver quem fala (olhar de frente)
8. evitar fazer anotações em excesso
9. ter tempo
10. respeitar opiniões alheia
11. procurar entender “chavões”
12. ouvir nas “entrelinhas”, o que não é dito, está implícito
13. não aceitar tudo como fato (pedir as provas, fontes)
14. pedir mais informações
15. usar frases reflectivas (onde, como, por que, quem, quando)
16. não fazer perguntas demasiadas

Ao falar:
1. preocupar-se com a audiência (interesses, conhecimentos)
2. usar meios visuais
3. usar humor (alternar informalidade e formalidade)
4. dialogar (”feedback”)
5. não tomar mais tempo que o assunto requer
6. restringir-se ao assunto
7. empregar palavras concretas, evitar adjetivos e floreios
8. não falar muito (usar frases curtas, uma idéia por vez, dar tempo para quem ouve raciocinar, pedir comentários, dividir o discurso em unidades)
9. repetir idéias com palavras ou por meios diferentes
10. não usar palavreado técnico
11. usar tons de vozes diferentes (entonação)

Liderando reuniões:
1. aceitar e explorar comentários despropositados
2. fazer o grupo voltar ao tema sem constranger outros
3. evitar reuniões paralelas (piadas, comentários para todo grupo)
4. não demonstrar autoridade5. não dar moral
6. não discutir, controlar o temperamento
7. quebrar aos poucos o gelo
8. aceitar idéias e sugestões
9. saber lidar com personalidades diferentes (os que falam muito, pouco, não têm opinião ou não gostam de expô-la)
10. desenvolver o prazer da conversação
11. ativar o pensamento
12. fazer perguntas para estimular o pensamento

Atenção:
1. três níveis (a não atenção, o apenas ouvir, o pensar)
2. conquistar e manter a atenção
3. Ao final da reunião:
4. rever as decisões mais importantes tomadas na reunião
5. pedir posições e compromissos
6. fazer plano de ação
7. marcar novas reuniões (não deixar para marcar depois)
8. fazer a ata (decisões feitas, argumentos usados, alternativas descartadas, motivos da escolha)

Depois:
1. pensar no que foi dito e não foi registrado
2. analisar os dados coletados
3. distribuir a ata aos participantes
LEMBRE-SE: as pessoas são diferentes, têm interesses, conhecimentos, objetivos e prioridades diferentes, portanto, “cada caso é um caso”.

5.2 QUESTIONÁRIO PARA COLETA DE DADOS

O questionário de pesquisa e usado com freqüência para obter informações. Essa ferramenta e muito conveniente quando há um grande número de usuários, o que geralmente ocorre em grandes organizações, em que diversos grupos de usuários podem estar em diversos locais diferentes do país. Nessas situações não seria prático entrevistar todas as pessoas de todos os locais. Mais para frente, tão logo as informações obtidas através de questionários tenham sido analisadas, podem-se fazer entrevistas específicas de acompanhamento com usuários selecionados, cuja contribuição em potencial pareça mais importante.

Os questionários de pesquisa têm algumas desvantagens. Uma desvantagem seria e que a comunicação com os usuários é seriamente restringida; não há uma real troca de informações face a face. Por essa razão, a decisão de usar um questionário de pesquisa deve ser cuidadosamente pesada em relação as desvantagens. Tipicamente, a preparação de um questionário bem redigido exige um tempo considerável Além disso, as questões devem ser estruturadas de maneira que façam sentido para as pessoas que as responderão. O ideal e que sejam formuladas sem preocupação com a forma como os usuários as responderão.Podem ser usados diversos formatos para o questionário; múltipla escolha, lista de verificação (checklist), questões com espaços em branco são alguns dos exemplos. Em qualquer caso, o questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta. Pode ser vantajoso permitir que o respondente faça a escolha em uma lista de verificação com um círculo em volta da resposta. Isso também facilitará a compilação dos resultados de um grande número de questionários. A discussão a seguir esboça as etapas a serem seguidas quando se usam questionários de pesquisa.

a) Preparação do questionário.
Identifique o tipo de informações que deseja obter, como problemas experimentados ou oportunidades a explorar.
Tão logo os requisitos tenham sido definidos, escolha um formato apropriado para o questionário. Monte as questões de forma simples, clara e concisa.
Se forem incluías questões que exijam uma resposta descritiva, assegure-se de deixar espaço suficiente para a resposta.
As questões que se voltam para tópicos específicos devem ser agrupadas em conjunto sob um titulo especial.
Idealmente, o questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização.

b) Identificar os respondentes.
O questionário pode ser personalizado através da inclusão do nome, função e localização de cada respondente.
Deve ser desenvolvido um controle que identifique todas as pessoas que recebendo os questionários. Ele será usado para monitorar o status dos questionários que foram distribuídos.

c) Distribuição do questionário.
Distribua o questionário, junto com instruções detalhadas sobre como preenchê-lo Indique claramente o prazo para a devolução do questionário.

d) Análise das respostas dos respondentes.
Analise e consolide as informações fornecidas pelos questionários devolvidos.
Documente as principais descobertas.
Envie uma copia do relatório das principais descobertas para cada respondente como cortesia pelo tempo dedicado a pesquisa.

O que procura-se identificar com o questionário

1. A Organização e seus Objetivos:
1.1 Quais os objetivos da Organização (determina prioridades)?

1.2 Qual o seu mercado de atuação?

2. As áreas da Organização e seus Objetivos:
2.1 Quais as divisões da Organização (em áreas, setores, departamentos, seções, assuntos, etc)?
2.2 Qual a missão e a colaboração de cada divisão dentro da Organização (responsabilidades)?
2.3 Quais os objetivos particulares de cada divisão?

3. Os Clientes/Usuários da Organização:
3.1 Quem são os usuários/clientes da Organização?
3.2 Quais os benefícios da Organização aos seus usuários/clientes?
3.3 O que os usuários desejam da Organização?
3.4 Que funções a Organização desempenha para alcançar a satisfação destes desejos?
Descrever informalmente cada uma das funções para melhor serem entendidas.
3.5 Que outras funções são necessárias para manter a Organização?
Descrever informalmente cada uma.
3.6 O que os usuários gostariam que melhorasse nos serviços da Organização (quais as reclamações, insatisfações, sugestões – desejos insatisfeitos dos usuários)?

4. Os Funcionários e suas Atribuições dentro de cada área:
4.1 Listar todos os funcionários que trabalham na Organização (em todos os escalões): cargo, funções, decisões tomadas, número de pessoas semelhantes (com mesmas atribuições). Descrever informalmente as funções e decisões.
4.2 Quais as insatisfações dos funcionários no desempenho de suas tarefas?
O que seria necessário para melhorar o desempenho das tarefas?
Que informações e dados seriam ou poderiam ser úteis para um melhor funcionamento da Organização (quanto a operações internas)?
4.3 O que seria necessário para melhorar os serviços da Organização (para atender os desejos insatisfeitos dos clientes)?
Que informações e dados seriam ou poderiam ser úteis para melhorar os serviços externos da Organização?
4.4 Quais as situações críticas que ocorrem nas tomadas de decisões da Organização?
4.5 Que funções e registros podem ser acrescentados para melhorar o funcionamento da Organização, com base nas respostas às perguntas
3.6, 4.2, 4.3, 4.4 (somente os que não existem nem manualmente)?

5. Os Registros, Cadastros, Arquivos e Relatórios Internos:
5.1 Que cadastros, arquivos, registros e outras informações são mantidos pela Organização e com que finalidade?
5.2 Que relatórios internos à Organização existem?

6. Os órgãos Externos relacionados à Organização:
6.1 Citar os fornecedores ou mantenedores da Organização e o que fornecem.
6.2 Citar outros órgãos externos à Organização com quem esta possui algum relacionamento. Indicar o relacionamento.
6.3 Que relatórios ou informações precisam ser passados para estes órgãos (qual o fluxo de informação)?

7. O Futuro da Organização:
7.1 Citar possíveis mudanças futuras na organização ou nos objetivos da Organização.
7.2 Citar as necessidades da Organização (do ponto de vista da própria Organização)?
7.3 Quais as expectativas da Organização quanto ao implante do processamento de dados?

5.3 REVISÃO DA DOCUMENTAÇÃO

Revisão da documentação é uma das formas mais populares de obter informações sobre a situação atual. Manuais de procedimentos internos, documentação de sistemas existentes, relatórios produzidos pelo sistema atual todos são importantes fontes de informações que descrevem o ambiente do usuário. (Vale a pena mencionar que a revisão da documentação pode ser executada antes, durante e depois de outras técnicas de obtenção de dados.) Freqüentemente, a multiplicidade de documentos que fluem através do ambiente justifica a necessidade de se fazer um inventário do que existe atualmente em termos de formulários, relatórios e outros documentos similares. Esta lista será um ponto útil de referência para o planejamento e organização de entrevistas e observações. Além disso, se mostrará muito útil durante a fase seguinte, quando serão necessárias informações mais detalhadas acerca do ambiente existente. Alguns itens de documentação que podem ser obtidos neste estágio incluem:

Ambiente manual dos usuários

Diagramas existentes que retratem a estrutura hierárquica da organização dos usuários.
Conjunto de documentos de entrada/saída que é usado para executar as atividades manuais do sistema. Pode incluir diferentes tipos de formulários, relatórios ou procedimentos departamentais.
Descrição dos atuais arquivos manuais.
Documentos que descrevam a natureza das interfaces manuais existentes entre o ambiente dos usuários e ambientes de outros grupos dentro ou fora da organização.
Documentos que descrevam as políticas corporativas que regulam as atividades dos negócios exercidas nas áreas dos usuários.

Ambientes automatizados

Principais características de configurações de hardware/software/rede em que o sistema rode.
Programas batch do sistema, junto com amostras de relatórios produzidos, bem como identificação dos receptores.
Transações on-line do sistema, junto com layouts de suas telas relacionadas.
Operações do sistema em tempo real.
Estruturas de arquivos e bancos de dados do sistema, junto com amostras de seus registros ou layouts de segmentos.
Descrição das interfaces do sistema.
Documentos fonte usados para alimentar o sistema computadorizado, junto com amostras de cada documento.
Uma cópia dos manuais de sistema do usuário.
Documentação do sistema que descreva os principais componentes do sistema existente

5.4 ANÁLISE DE OBSERVAÇÃO (Observação Direta)

A análise de observação é uma técnica de obtenção de fatos muito efetiva. Ela pode ser usada para diversas finalidades, como processamento e confirmação dos resultados de uma entrevista, identificação de documentos que devem ser coletados para análise posterior, esclarecimento do que esta sendo feito no ambiente atual, e como está sendo feito, e tarefas similares. A técnica e relativamente simples. Durante algum tempo, o analista observa os usuários em seu ambiente enquanto eles executam suas atividades diárias. Apesar de o analista poder observar sem intervir diretamente no processo, na maioria das vezes, ele interagirá com a pessoa que está sendo observada. Freqüentemente o analista fará perguntas para conhecer o funcionamento da operação. No limite do possível, o analista deve executar as atividades do usuário, para entender melhor como o usuário opera em seu próprio ambiente.A análise de observação pressupõe que, em primeiro lugar, foi garantida a aprovação das gerências apropriadas. E também muito importante explicar para as pessoas que serão observadas o que você vai fazer e por que. Essas medidas de precaução ajudarão a evitar situações em que a pessoa observada se sinta sob pressão. As etapas abaixo identificam as principais atividades que devem ser executadas antes, durante e depois do estudo de observação.

Antes

Identificar as áreas de usuário a serem observadas.
Obter a aprovação das gerencias apropriadas para executar as observações.
Obter os nomes e funções das pessoas-chave que sendo envolvidas no estudo de observação.
Explicar a finalidade do estudo.

Durante

Familiarizar-se com o local de trabalho que está sendo observado.
Observar os agrupamentos organizacionais atuais.
Observar as facilidades manuais e automatizadas em use atualmente.
Coletar amostras de documentos e procedimentos escritos que são usados para cada processo especifico que esta sendo observado.
Acumular informações estatísticas a respeito de tarefas: freqüência em que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada e assim por diante.
Enquanto interage com os usuários, tente sempre ser objetivo e não comentar as formas de trabalho de maneira não construtiva.
Além das operações normais de negocio, observe também as exceções.
Tão logo as observações tenham sido completadas, agradeça as pessoas pelo apoio.

Após

Documente as descobertas resultantes das observações feitas.
Consolide os resultados.
Reveja os resultados consolidados com as pessoas observadas e/ou com seus superiores.Em circunstâncias particulares, a análise de observação tem algumas desvantagens. Por exemplo, o processo global pode consumir bastante tempo. Ou mesmo pode haver uma interferência muito grande por parte do observador no trabalho desenvolvido pelo objeto de observação, invalidando o método.

5.5 ANÁLISE DE SISTEMAS EXISTENTES

A análise de sistemas existentes é uma forma importante de análise das possibilidades a serem consideradas como requisitos do sistema. Esta prática é bastante utilizada com usuários inexperientes ou que não conseguem descrever as funcionalidades que o sistema deve possuir.É importante salientar usuários sem experiência com sistemas tendem a procurar apenas a automação dos processos atuais, não identificando novas oportunidades. Freqüentemente, são encontrados em outros sistemas já amadurecidos, uma significativa inspiração para a identificação de requisitos para o sistema. Essa inspiração pode ser buscada em sistemas executados na própria empresa contratante, em sistemas produzidos pela empresa que está especificando o software ou em outros sistemas existentes no mercado.De qualquer forma, é importante não limitar-se apenas às observações apresentadas pelo usuário, sob pena da especificação ficar muito limitada, portanto sujeita à intensas alterações futuras.

6. Avaliação da Qualidade de uma Especificação de Requisitos de Software

[Paula Filho 03].

6.1 Aspectos a serem considerados para avaliação da qualidade de um documento de requisitos.

6.1.1. Verificação do texto

1. Todos os textos estão em português correto.
2. Os textos de todas as figuras e diagramas estão em português correto.
3. Os textos de todas as figuras e diagramas são legíveis.
4. A numeração de todas as páginas está correta.
5. Não há quebras de página desnecessárias.
6. Os estilos de texto são consistentes em todo o documento.
7. Todas as tabelas estão com a numeração correta.

6.1.2 Apresentação

1. O nome do documento consta da ERSw.
2. A identificação do projeto consta da ERSw.
3. O número de versão revisada do documento consta da ERSw, mas não para o documento inicial.
4. Os nomes dos autores e de suas respectivas organizações constam da ERSw.
5. A data de emissão consta da ERSw.
6. As datas de aprovação constam da ERSw.
7. As assinaturas de aprovação constam da ERSw.
8. A lista dos números de revisão e das datas de aprovação das revisões anteriores consta da ERSw.
9. A disposição desses itens na página de título está de acordo com o padrão.
10. Existe um sumário, se o documento tiver mais de oito páginas.
11. Os números das páginas indicados estão de acordo com o documento.
12. Os números das seções estão de acordo com o documento.
13. O nome de cada interface, diagrama e caso de uso está igual ao que aparece no título da respectiva seção do documento.
14. Se existir lista de ilustrações, todas as figuras nela indicadas realmente estão presentes no documento, com os devidos nomes.
15. Se existir lista de ilustrações, todas as figuras contidas no documento estão presentes na lista de ilustrações.

6.1.3 Introdução e Descrição Geral

1. O público do documento de ERSw está claramente identificado e delimitado.
2. O produto a ser desenvolvido está claramente identificado pelo nome.
3. Está claramente explicado o que o produto do software fará e, caso necessário para evitar falsas expectativas, o que não fará.
4. Está claramente descrita a aplicação do produto especificado, inclusive seus benefícios, quantificados se possível.
5. Esta subseção é consistente com outros possíveis documentos de nível mais alto.
6. São indicadas referências bibliográficas completas, no caso de livros e periódicos.
7. No caso de documentos sem referências bibliográficas, é indicado como eles poderão ser obtidos.
8. Os termos são definidos de forma clara e compreensível.
9. Todas as siglas utilizadas no documento estão definidas.
10. A terminologia usada é inteligível para os usuários.
11. A terminologia usada para o domínio da aplicação é consistente com o jargão dessa área.
12. A terminologia de informática é consistente com o glossário do processos e outros padrões de nomenclatura de informática (ex.: UML ou IEEE).
13. Esta subseção reflete corretamente a estrutura do restante da ERSw, indicando todas as subseções incluídas na seção 4 e todas as personalizações realizadas nas seções anteriores.

6.1.4 Requisitos Específicos – Consistência

1. Termos definidos no glossário não são usados como nome de interfaces.
2. Em todas as tabelas onde aparece a coluna “interface” o nome desta está igual ao que aparece no sumário.
3. Termos definidos no glossário não são usados como nome de casos de uso.
4. Em todas as tabelas onde aparece a coluna “caso de uso”, o nome deste está igual ao que aparece no sumário.
5. Termos definidos no glossário não são usados como nome de atores.
6. Todos os atores humanos da coluna “ator” estão representados no diagrama de contexto.
7. Todos os atores humanos representados no diagrama de contexto estão presentes em pelo menos uma linha da coluna “ator”.
8. Cada par formado por ator humano e caso de uso, relacionado no diagrama de contexto, corresponde a pelo menos uma interface de usuário.
9. Todos os casos de uso primários ou secundários que têm comunicação direta com algum ator humano estão presentes no diagrama de contexto.
10. Todos os atores sistêmicos (representativos de sistemas externos) da coluna “ator” estão representados no diagrama de contexto.
11. Todos os atores sistêmicos representados no diagrama de contexto estão presentes em pelo menos uma linha da coluna “ator”.
12. Cada par formado por ator sistêmico e caso de uso, relacionado no diagrama de contexto, corresponde a pelo menos uma interface de sistema (software, hardware e comunicação).
13. Todos os casos de uso primários ou secundários que têm comunicação direta com algum ator sistêmico estão presentes no diagrama de contexto.
14. Toda função pode ser associada pelo menos a uma das interfaces definidas nas subseções anteriores.
15. Toda função pode ser associada a um caso de uso no diagrama de contexto.
16. Todos os usuários e sistemas externos listados correspondem a atores presentes no diagrama de contexto.
17. Todos os atores apresentados no diagrama de contexto estão listados.
18. Todos os usuários estão listados na subseção anterior.
19. Todos os atores humanos apresentados no diagrama de contexto estão listados.

6.1.4 Requisitos Específicos – Conteúdo

1. O diagrama apresentado é claro e pode ser compreendido sem textos complementares.
2. Foram incluídos atores para representar todos os elementos relevantes do ambiente do produto.
3. São identificadas todas as interfaces do produto com os seus usuários humanos.
4. As denominações das interfaces de usuário são adequadas.
5. São identificados os atores e casos de uso associados com cada interface de usuário.
6. É apresentada uma descrição sucinta que resume de forma adequada o propósito da interface.
7. São identificadas todas as interfaces do produto com os sistemas externos relevantes.
8. As denominações das interfaces de sistema (hardware, software e comunicações) são adequadas.
9. São identificados os atores e casos de uso associados com cada interface de sistema.
10. É apresentada uma descrição sucinta que resume de forma adequada o propósito da interface de sistema.
11. Não são incluídas interfaces rotineiras e transparentes para o produto, que sejam partes usuais do ambiente operacional
12. Foram descritos os requisitos de configurações de memória primária e secundária.
13. Foram descritos os requisitos dos modos normal e especiais de operação.
14. Foram descritos os principais requisitos relativos a adaptações do produto aos locais onde será implantado.
15. Nenhuma função listada está fora dos limites do produto, definidos na subseção Limites do produto
16. Todas as funções estão claramente descritas.
17. A lista dos usuários é consistente com o escopo do produto, como definido na subseção Escopo do produto.
18. A caracterização da comunidade de usuários foi suficientemente detalhada.
19. A subseção descreve aspectos relevantes que possam limitar as opções dos desenvolvedores, e apenas esses aspectos.
20. A subseção descreve fatores técnicos que se supõe sejam atendidos para que o produto possa ser desenvolvido e implantado, e apenas esses aspectos
21. A lista do requisitos aqui arrolados é consistente com a subseção Escopo do produto.

6.1.5 Interface do Usuário

1. A interface é listada na subseção Perspectiva do Produto – Interfaces de usuário.
2. O diagrama de estados, se utilizado, é consistente com os leiautes: cada leiaute corresponde a pelo menos um estado.
3. As outras interfaces listadas na subseção Relacionamentos com outras interfaces estão listadas na subseção Perspectiva do Produto – Interfaces de usuário.
4. Todos os campos apresentados no leiaute estão listados.
5. Todos os campos listados estão indicados no leiaute, se forem visíveis no estado representado.
6. Todos os comandos apresentados no leiaute estão listados.
7. Todos os comandos listados estão indicados no leiaute, se forem visíveis no estado representado.
8. Na subseção Comandos, não estão sendo utilizados para os comandos termos indicativos de desenho (botão, opção etc.).
9. Na subseção Comandos, todas as referências a comandos estão em itálico.
10. Na subseção Comandos todas as referências a interfaces (telas) estão em itálico.
11. Em todas as tabelas, o caractere – é utilizado para indicar células sem conteúdo.
12. O diagrama de estados, se utilizado, está em UML correta.
13. A descrição da interface não avança em detalhes de desenho, não pertinentes a requisitos.

6.1.6 Interface do sistema

1. A interface é listada na subseções (Interfaces de hardware) e (Interfaces de comunicação).
2. As outras interfaces listadas na subseção Relacionamento com outras interfaces estão listadas na subseção Perspectiva do produto.
3. É descrita a fonte da entrada, se e somente se houver fluxo de dados do ator para o produto.
4. É descrito o destino da saída, se e somente se houver fluxo de dados do produto para o ator.
5. A descrição da interface não avança em detalhes de desenho, não pertinentes a requisitos.

6.1.7 Diagrama de Caso de Uso

1. Todos os atores representados nos diagramas estão listados na seção (Usuários e sistemas externos – Descrição).
2. Todos os casos de uso representados nos diagramas estão listados na seção (Funções do produto).
3. Para cada par ator / caso de uso presente nos diagramas há uma interface definida na seção (Perspectiva do produto).
4. Cada diagrama é consistente com os demais diagramas de casos de uso, inclusive o diagrama de contexto.
5. Cada diagrama é necessário para o bom entendimento dos relacionamentos entre casos de uso e atores.
6. Os relacionamentos entre casos de uso e atores foram expressos corretamente em cada diagrama.
7. Os relacionamentos entre casos de uso foram expressos corretamente em cada diagrama.

6.1.8 Fluxos dos Casos de Uso

1. O caso de uso detalhado está listado na seção (Funções do produto).
2. As inclusões e extensões são consistentes com o diagrama de contexto e os diagramas de casos de uso.
3. Os atores referenciados são consistentes com o diagrama de contexto e os diagramas de casos de uso.
4. Todos as inclusões referenciam casos de uso existentes e devidamente detalhados.
5. Se o caso de uso for de inclusão, ele é referenciado em pelo menos um passo de cada caso de uso de base, sendo essa inclusão documentada em um diagrama.
6. Se o caso de uso for de extensão, ele corresponde a um ponto de extensão no caso de uso de base, referenciado nas precondições deste caso, sendo essa extensão documentada em um diagrama.
7. O diagrama de estados, se utilizado, está de acordo com a descrição.
8. Se forem utilizados tanto fluxos textuais quanto o diagrama de estados, eles são consistentes entre si.
9. O sujeito gramatical de cada passo do caso de uso é o produto ou um ator (geralmente humano) que inicia uma ação.
10. Os sistemas externos relacionados com o caso de uso são objetos gramaticais de passos, quando a comunicação é iniciada pelo produto.
11. Nenhum passo referencia mais de um ator humano.
12. O caso de uso não referencia mais de um ator humano, exceto em modelagem de fluxos de trabalho.
13. Todas as referências a atores estão sublinhadas.
14. Todas as referências ao produto estão sublinhadas em negrito.
15. Todas as referências a interfaces e seus elementos estão em itálico.
16. Todas as referências a pontos de extensão estão com a seguinte formatação: <ponto de extensão: nome do ponto de extensão> ou <início ponto de extensão: nome do ponto de extensão > ou <fim ponto de extensão: nome do ponto de extensão >
17. Para cada indicação de início de ponto de extensão existe uma indicação de fim de ponto de extensão.
18. Os passos são claros e bem apresentados.
19. Os passos são descritos com o nível de detalhe adequado.
20. Todas as interações com atores são definidas e descritas de forma correta.
21. Todas as precondições são definidas e descritas de forma correta.
22. O fluxo do caso de uso é consistente com a descrição contida na seção 2.2 (Funções do produto).
23. Foram definidas as precondições para o caso de uso.
24. Para todos os fluxos alternativos as precondições foram definidas.
25. Diagramas de estado ou diagramas de atividade são usados para esclarecer comportamentos complexos.
26. Diagramas de estado ou diagramas de atividade são claros e bem apresentados.

6.1.9 Requisitos não funcionais

1. Os requisitos de desempenho são consistentes com as restrições contidas na subseção Restrições.
2. Os requisitos de desempenho são especificados de forma clara, compreensível, quantitativa e mensurável.
3. O diagrama de dados persistentes é consistente com o diagrama de contexto e as interfaces de software.
4. Todas as classes presentes no diagrama de dados persistentes são descritas.
5. Se forem listados requisitos relativos a classes persistentes específicas, estes são formulados de forma clara, compreensível e testável.
6. As restrições ao desenho são consistentes com as restrições contidas na subseção Restrições.
7. As restrições ao desenho são formuladas de forma clara, compreensível e testável.
8. As restrições ao desenho não incluem decisões de desenho internas ao projeto.
9. Os atributos da qualidade são formulados de forma clara, compreensível, quantitativa e mensurável.
10. Os atributos da qualidade são formulados de maneira consistente com o padrão ISO‑9126.
11. Outros requisitos são formulados de forma clara, compreensível e testável.

7. Bibliografia

[IEEE 90] IEEE STD 610.12-1990: Standard Glossary of Software Engineering Terminology.

[IEEE 98] IEEE STD 830-1998: IEEE Recommended Practice for Software Requirements Specifications

[IEEE 00] BERRY, Daniel M. The Requirements Iceberg & Various Ice Picks Chipping At It
– University of Waterloo, Canada, 2002.

[Pfleeger 04] PFLEEGER, Shari L. Engenharia de Software: teoria e prática. São Paulo: Prentice-Hall, 2004.

[Paula Filho 03] PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

---

[1] Institute of Electrical and Electronics Engineers, Inc.

Plugins do WordPress e Yahoo para adaptar em seu Site!

WordPress

Para baixar e instalar o WordPress entre nesse site e siga os passos do arquivo de instalação.

Mas o divertido mesmo, são os plugins para daptar em sites. Acesse aqui!!

Yahoo

No site do Yahoo também possui componentes em flash, que podem ser facilmente adaptados a sites.Aqui por exemplo possui gráficos em flash alimentados por array. Acesse o flash developer do yahoo aqui!!

Otimização de sites

Pra quem uma empresa de web vende hoje?
Uma empresa de web vende primeiro pro google, depois para seus clientes, pq?

Fiz uma pesquisa breve sobre seo, creio que não seja apenas uma tendência, e que estamos bem atrasados nesse sentido..

1. primeira página do Google (SEO)
   

• Empresa que otimiza sites – (vantagem competitiva, cases, primeiros passos,…) http://www.publiweb.com.br/otimizacao-de-sites.htm
• Empresa que otimiza sites – (vantagens em números) – http://www.buscatopo.com.br/
• Empresa que otimiza sites – (vantagens) – http://www.pensedynamo.com/consultoria-otimizacao-sites.htm
• Wikipedia (explicação básica) – http://pt.wikipedia.org/wiki/Otimiza%C3%A7%C3%A3o_para_Sistemas_de_Busca

Claro, acho que a primeira necessidade será a padronização de códigos, pois isso possibilitará um alto reaproveitamento de código, o que implica diretamente em retrabalho muito menor (pois um código reaproveitado ja foi testado e aprovado pelo cliente). Alem de carta na manga, quando for visitar um cliente teremos um leque de ferramentas que vamos poder oferecer com prazos menores, e por isso, maior lucratividade.

Manager

Esse é o primeiro Layout do meu gerenciador de conteúdos para sites(comercialmente chamado de Manager).

Creio que precise ser aprimorado em diversos aspectos, até porque, ele não prevê um fluxo de dados muito grande. E para uma demanda restrita de dados, se mostra bastante ágil e de fácil atualização e manutenção no conteúdo, pois possibilita ao usuário inserir e atualizar um determinado conteúdo sem que precise sair da página.

A dinâmica do gerenciador foi estudada afim de disponibilizar ao cliente a forma mais rápida e eficiente possível de manipular as informações do site. Talvez por isso, deva ser estudada algumas formas de garantir mais segurança na informação. Colocando avisos destacados, para cada conteúdo a ser atualizado, evitando assim, que nosso cliente coloque informações desnecessárias na página.

1° tela – Login de usuário.

2° tela – Estatísticas de acessos no site.

3° tela – Tela de edição e inserção de Clientes.

Layout do site da M@kt

Layout do site da M@kt

Cliente que trabalha com E-mail Marketing.

Esse é o primeiro site que estou fazendo 100% por conta própria.

Tenho certeza que será um grande trabalho, e que vai me dar uma experiência legal, em diversas áreas as quais não estou acostumado a trabalhar.