Mostrando postagens com marcador Conceitos. Mostrar todas as postagens
Mostrando postagens com marcador Conceitos. Mostrar todas as postagens

terça-feira, 21 de março de 2017

Fatores de qualidade de McCall

10:31


cCall, Richards e Walters (McC77 Apud Pressman, 2016 Capítulo 19, pág. 416) criaram uma proposta de categorização de fatores que afetam a qualidade de software:



Operação do Produto (Características
operacionais)

Correção: Atende a especificação e aos objetivos do cliente.

Confiabilidade: Realiza a função pretendida com a precisão exigida.

Usabilidade: Esforço para utilizar, aprender, preparar as entradas e interpretar as saídas.

Integridade: Controle de acesso ao software e aos dados apenas para pessoas autorizadas (segurança).

Eficiência: Quantidade de recursos computacionais e código exigidos para uma função.

Revisão do Produto

Facilidade de manutenção: Esforço necessário para localizar e corrigir um erro (e para evoluir o software).

Flexibilidade: Esforço necessário para modificar um programa em operação.

Testabilidade: Esforço necessário para modificar um programa em operação.


Transição do produto 

Portabilidade: Esforço para transferir um software de um ambiente (hardware/ software) para outro.

Reusabilidade: Esforço necessário para testar um programa para garantir que ele desempenhe a função pretendida. O quanto um programa ou partes do programa pode ser reuitizado em outras aplicações.

Interoperabilidade: Esforço necessário para integrar o software a outros sistemas.

Abraços...


segunda-feira, 20 de março de 2017

Qualidade de software

11:08


Para você o que é qualidade de software?
O entendimento de qualidade de software pode váriar, por pessoa e por papel, então vamos ver alguns exemplos!
Cliente (solicitante): Se o produto gera ganhos e benefícios para o negócio.


Usuário: Se o produto atende as metas e expectativas do usuário.

Empresa fornecedora do software: Se o produto gera ganhos para o fornecedor, se é um produto competitivo em relação aos concorrentes.

Equipe técnica (analistas e desenvolvedores): Se o produto atende a requisitos funcionais e técnicos de performance, segurança e evolução.

Área de controle de qualidade: Se o processo de desenvolvimento está em conformidade com os padrões de qualidade definidos.


O que é qualidade de software?

Para entender e definir o o que é qualidade de software, é necessário considerar:

As diferentes visões e expectativas dos envolvidos na criação utilização e evolução do software.
   
- Fatores de qualidade em todo o ciclo de vida do software

 Os ganhos gerados por um software de qualidade

 - Manutenção e evolução do software com custos controlados
- Agilidade nos processo de trabalho que utilizam o software
- Maior competitividade do software (com os produtos concorrentes)

 Os impactos da baixa qualidade de software

 - Alto custo (principalmente a longo prazo)

- Perdas para o negócio


Agora vamos lá, Qualidade de software é quando o SW atende os requisitos do negócio, fornece uma experiência pro usuário satisfatória e tem uma quantidade minima aceitável de defeitos.(Adaptado de Forrester, Apud Gualtieri, 2010).

 Qualidade de software está relacionada com satisfação do cliente, mas envolve outros fatores, entre os quais podemos considerar:

 [SW de qualidade] = [Produto útil e compatível com uma necessidade] + [Processo de desenvolvimento de um produto controlado] + [Entrega dentro do orçamento e do prazo estipulado] + [Agrega valor para o fabricante e o usuário]

 Abraços!

sexta-feira, 17 de março de 2017

XP - eXtreme Programming

17:45





E ai malandros, mais um post humilde para seus cultivadores e acumuladores, vocês sabem, aqui tem conhcimento de quase tudo, chorem.
O que é XP – Extreme Programming
A proposta do XP (BECK, 2005).É um estilo de desenvolvimento de SW que prioriza:

- Excelência na aplicação de técnicas de programação.

- Comunicação clara.

- Trabalho em EQUIPE.

- Fundamentado em VALORES, que utiliza PRÁTICAS (comprovadas como úteis), é orientado por PRINCÍPIOS (que direcionam a ação em situações onde não há uma prática reconhecida), e que executa ATIVIDADES essenciais em todo o ciclo do XP.

XP – Extreme Programming (1999)

XP é uma metodologia leve, para times de tamanho pequeno a médio, desenvolvendo software em face a requisitos vagos ou que mudam rápido.” (BECK, 1999 Apud BECK, 2005 – tradução nossa)

• Leve : mais foco na entrega de valor para o cliente do que nas atividades de documentação e controle.

• Metodologia que pode ser usada por times de qualquer tamanho

• Inicialmente pensada para times pequenos e médios,

• Foi utilizada com sucesso por times grandes (Kent Beck, 2005)

• Adaptável a requisitos vagos ou que mudam rápido.

XP – Extreme Programming (2005)

Segundo Kent Beck (2005), XP é uma metodologia leve, para times de qualquer tamanho, desenvolvendo software em face a requisitos vagos ou que mudam rápido.

• Leve : mais foco na entrega de valor para o cliente;

• Metodologia que pode ser usada por times de qualquer tamanho

• Os valores e princípios do XP podem ser aplicados a times de qualquer tamanho,
mas as práticas sugeridas originalmente para o uso do XP devem ser alteradas quando muitas pessoas estão envolvidas (Kent Beck, 2005).

• Adaptável a requisitos vagos ou que mudam rápido.

 Principios

 Fazer um trabalho de qualidade, mudar incrementalmente, feedback rápido, aceitar mudanças e adotar a simplicidade.

 Valores

 Comunicação, simplicidade, feedback, coragem e respeito.

 Atividades

 Ouvir, testar, codificar, projetar.

 As práticas adotadas, só você unir tudo que eu acabei de dizer, que automaticamente você terá a resposta.

 Tal como, Padrões de codificação, ritmo sustentável. 

 Jogo de planejamento, programação em par, refatoração Desenvolvimento guiado por testes (TDD).

Versões pequenas.

 Integração contínua, posse coletiva do código.

 Papeis da equipe de XP

 Gerente de projetos

 * Acredita na efetividade da metodologia XP e segue valores.

 * Tem práticas e princípios do XP, promovendo sua aplicação pela equipe e em todo o projeto de SW.

 * Principal contato com o cliente, estimula a participação ativa do cliente.

 * Organiza o início do projeto e garante o ritmo do desenvolvimento.
Coach

 * Vasta experiência e profundo conhecimento em XP, domina valores, práticas e princípios do XP.

 * Monitora a equipe e garante a aplicação adequada do XP pela equipe e em todo o projeto de SW.


 * Mentoria para questões relativas ao XP.
Desenvolvedor

 * Conhecimento de análise e programação: projetista, designer, analista, programador, analista de banco de dados.

 * Programação em par: sempre um com experiência, multiplicando conhecimento e contribuindo para o desenvolvimento profissional.
Analista de Testes

 * Responsável por elaborar casos de teste junto ao cliente e aplicá-los nos final de cada iteração.
Redator Técnico

 * Responsável pelas documentações necessárias (mesmo que seja uma documentação mínima de uma abordagem ágil e sem burocracias).
É isso ai galera, flws...

terça-feira, 14 de março de 2017

Processo de desenvolvimento de um SW com Scrum

17:51
Como dizem por ai, é melhor qualidade do que quantidade, aqui irei abordar o processo do scrum em uma equipe de desenvolvimento de software de forma bem eficaz! Vamos lá cambada.

Faz de conta que somos uma equipe, e vamos desenvolver um grande software (SW) para ficarmos ricos! 

Nessa equipe, ambos os integrantes devem ter seus respectivos papéis, quais seriam esses papéis?

Existe o Cliente, Project Ownner (PO), Scrum Master e os desenvolvedores.

Product Owner (PO) – dono do produto

Define o produto (visão e funcionalidades) e lançamento das versões (resultado das iterações – executadas em sprints)

Define prioridades – elabora e mantém o backlog do produto

Scrum Master (SM)

Apoia o PO com o backlog do produto

Agiliza o trabalho: remove impedimentos, protege a equipe,
aplica valores e práticas Scrum.

Time de Desenvolvimento (ou equipe scrum)

Faz as estimativas e define as tarefas necessárias,

Desenvolve o produto, garante a qualidade,

Apresenta o produto para o cliente.

Cliente

Vou deixar uma imagem do scrum:

Como esse grupo vai funcionar:

1 -  PO e Cliente: Apresentam itens candidatos ao backlog de produto e
definem prioridades;

2 - Planejamento da Sprint: O time seleciona o que será feito na Sprint, PO e SM participam (uma primeira sprint de planejamento, projeto do SW, arquitetura, melhor entendimento dos itens);

3. SM mantém o Sprint Backlog (iteração trabalho para 2 a 4 semanas);

4. Reunião diária: 3 perguntas. SM conduz e time se posiciona.

5. Revisão da Sprint: o PO avalia o produto gerado, aceita ou não.- o Cliente participa.

6. Retrospectiva da Sprint.

É isso ai né galera? Ta ótimo, flw.

segunda-feira, 12 de dezembro de 2016

UML - Diagrama de atividades

15:10


É o diagrama com maior ênfase a visão do processo a nível do usuário. Apresenta muitas semelhanças com os fluxogramas.

Estado inicial

Determina o início de um Diagrama de Atividades, ou seja, o momento a partir do qual parte o processo.

O Estado Inicial é representado por um círculo preenchido.


Estado Final

Indica o final do Diagrama de Atividades.

O Estado Final é representado por um círculo não preenchido envolvendo um segundo círculo preenchido.


Estado de ação

Representa a realização de uma ação dentro de um fluxo de controle.

Uma atividade costuma possuir diversos Estados de Ação.


Ponto de decisão

Representa um ponto do fluxo de controle onde deve ser realizado um teste, uma tomada de decisão.

As transições geradas por um Ponto de Decisão necessitam ser providas de uma Condição(texto entre colchetes) para determinar qual a condição do teste.


Nodo garfo

Representa um ponto onde recebe uma entrada do fluxo e gera diversas saídas.


Nodo Junção

Representa um ponto do fluxo onde recebe várias entradas e gera apenas uma saída.


Raias de natação

Com as raias de natação, procura-se identificar os diversos setores, departamentos ou mesmo os atores que interagem com um processo.

As Raias de Natação são formadas por retângulos representando divisões que identificam as zonas de influência.


UML - Diagrama de sequência

13:01

É um diagrama comportamental que procura determinar a sequência de eventos que ocorrem em um determinado processo, identificando quais mensagens devem ser disparadas e envolvidos e em que ordem.

Objetivo

- Determinar  a ordem em que os eventos ocorrem.

- As mensagens que são enviadas.

- Os métodos que são chamados.

- E como os objetos interagem dentro de um determinado processo. 

Atores

Os Atores declarados nesse diagrama, são estâncias dos diagramas de caso de uso, representando entidades externas que interagem com o sistema e que solicitam serviços.

Linha de vida

- Representa o tempo em que um objeto existe durante um processo.

- As linhas de vida são representadas por linhas verticais tracejadas partindo do retângulo que representa o objeto.

- A linha de vida é representada por um X quando o objeto é destruído.


Foco de controle ou ativação

- Indica os períodos em que um determinado objeto está participando ativamente de um processo.

- Os focos de controle são representado por uma linha mais grossa, dentro da linha de vida.


Mensagens

- As mensagens são utilizadas para demonstrar as concorrências de eventos, que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo.

- Quando uma mensagem ocorre entre dois atores, não dispara métodos.

– As mensagens são representadas por linhas entre dois componentes, contendo setas indicando qual o componente enviou a mensagem e qual a recebeu.

- Os textos contidos nas mensagens primeiramente identificam qual evento ocorreu e forçou o envio da mensagem e qual o método foi chamado.


Mensagens de Retorno

– Este tipo de mensagem identifica a resposta a uma mensagem para o objeto ou ator que a chamou.

– Pode retornar informações específicas do método chamado ou apenas um valor indicando se o método foi executado com sucesso ou não.


Auto chamadas

– São mensagem que o objeto envia para si mesmo.


Abraços


sábado, 10 de dezembro de 2016

UML - Diagrama de Classe

11:15

Aqui continuamos mais um artigo da série "UML"

Qual o objetivo do Diagrama de Classe?

Permitir a visualização das classes do sistema com seus respectivos atributos e métodos.

Demonstrar como as classes se complementam, se relacionam e transmite informações entre si.

Composto por classes e associações existentes entre elas.

Uma classe na linguagem UML é representada por um retângulo com até 3 divisões:

1 - Contêm a descrição ou nome da classe.

2 - Os atributos da classe.

3 - Os métodos da classe.

Atributos e métodos podem não ser representados no diagrama. 


Relacionamentos ou Associações

Um relacionamento ou associação descreve um vinculo que ocorre normalmente entre os objetos de uma ou mais classes.

Associação unária ou reflexiva.

Esse tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com os objetos da mesma classe.

A multiplicidade procura determinar o numero minimo e máximo de objetos envolvidos em cada extremidade da associação.

Associação Binária

Ocorrem quando são identificados relacionamento entre duas classes distintas.

É a associação mais encontrada nas situações.

A navegabilidade é representada por uma seta nas extremidades da associação, identificando o sentido que as informações são transmitidas entre os objetos das classes que estão envolvidas.


Associação ternária

São associações que conectam objetos de mais de duas classes.


Agregação

É um tipo especial de associação onde tenta demonstrar que as informações de um objeto (chamado objeto-todo) precisam ser complementadas pelas informações contidas em um ou mais objetos de outra classe (chamados objetos parte).


O símbolo agregação difere da associação por conter um losangulo na extremidade da classe que contém os objetos todo.


Composição

Constitui-se uma variação da agregação, onde é apresentado um vínculo mais forte entre os objetos-todo e os objetos-parte, procurando demonstrar que os objetos parte tem que estar associado a um único objeto-todo.

O Símbolo de composição diferencia-se graficamente do símbolo de agregação por utilizar um losango preenchido.

Generalização / Especialização

O objetivo dessa associação é representar a ocorrência de herança entre as classes.


Veja também:














quinta-feira, 8 de dezembro de 2016

UML - Diagrama de casos de uso

16:38

Fala galera, hoje o artigo vai ser sobre UML detalhando tudo sobre os Diagramas de caso de uso que muita gente se dar mal.

O diagrama de caso de uso concentra-se em dois itens principais, Atores e Casos de uso.

Atores

Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar, de alguma forma, os serviços e funções do sistema.

Representação gráfica

Casos de uso

Refere-se aos serviços, tarefas ou funcionalidades identificadas como necessárias ao software e que podem ser utilizados de alguma maneira pelos atores que interagem com o sistema.

Associações

Representam os relacionamentos entre:

- Os atores que fazem parte do diagrama.

- Entre os atores e os Casos de Uso.

- Entre os Casos de Uso e outros Casos de Uso.


Generalização / Especialização


É uma forma de associação entre os casos de uso na qual existem dois ou mais casos de uso com características semelhantes, apresentando pequenas diferenças entre si.

Inclusão

Costuma ser utilizado quando existe um canário, situação ou rotina comum a mais de um Caso de Uso.

A documentação desta rotina é colocada em um Caso de Uso especifico para que outros casos de uso utilizem esse serviço, evitando assim, descrever uma mesma sequencia de passos em vários Casos de uso.

Indicam uma obrigatoriedade de execução.


Extensão

Associações de extensão são utilizadas para descrever cenários opcionais de um Caso de Uso. Descrevem cenários que ocorrerão apenas em situações especificas se determinada condição for estabelecida.


Abraços

Artigos Relacionados:


UML - Diagrama de Atividades

UML - Diagrama de Sequencia
Assinar: Postagens (Atom)