Inteligência Artificial - 8 Rainhas

Noite inspirada a minha, postando tudo que vem na cabeça. Você já ouviu falar do desafio das 8 rainhas no Xadrez? Bom, este é um exemplo em que se pode usar heurística para encontrar as soluções já que o número de combinações é um pouco grande, no Calc (Excel like), consegui montar duas soluções, segue abaixo.


X X X X X R X X
R X X X X X X X
X X X X R X X X
X R X X X X X X
X X X X X X X R
X X R X X X X X
X X X X X X R X
X X X R X X X X


X X X X X R6 X X
X R1 X X X X X X
X X X X X X R7 X
R2 X X X X X X X
X X R3 X X X X X
X X X X R4 X X X
X X X X X X X R8
X X X R5 X X X X

Segundo o professor Helmuth, existem 96 combinações /4 = 24 originais. Meu grupo ficou a cargo de desenvolver o programa pra encontrar as soluções, parece que vamos fazer em Java, gostaria de fazer também em C# e Pascal -> Delphi, daqui uns dias posto aqui os fontes e mais detalhes sobre IA, é muito show!

Engenharia de Software - Parte V - Métodos Ágeis

Métodos Ágeis

Valores:
  • Adaptação a mudança mais do que seguir um plano;
  • Software funcionando é mais importante que documentação completa e detalhada;
  • Indivíduos e iterações são mais importantes que processos e ferramentas;
  • Colaboração do cliente mais do que negociação do contrato;
Princípios:
1: A mais alta prioridade é a satisfação do cliente através da libertação mais rápida e contínua de software de valor.
2: Receba bem as mudanças, mesmo em estágios tardios de desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.
3: Libere software com frequência de um par de meses, com preferência para uma escala de tempo mais curta, 2 ou 3 semanas.
4: Mantenha as pessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto.
5: Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.
6: O método mais eficiente e efetivo de passar informação entre uma equipe é através da conversação cara-a-cara, pessoalmente.
7: Software funcionando é a principal medida de progresso.
8: Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.
9: A atenção contínua para a excelência técnica e um bom projeto aprimora a agilidade.
10: Simplicidade – a arte de maximizar a quantidade de trabalho não feito é essencial. Fazer apenas o necessário.
11: As melhores arquiteturas, requerimentos e projetos emergem de equipes auto organizadas.
12: Em intervalos regulares as equipes devem refletir sobre como se tornarem mais efetivas e então refinarem e ajustarem seu comportamento de acordo. Buscar aumento de produtividade.


SCRUM

Framework de gerenciamento de projetos e controle. Libera funcionalidades a cada 30 dias. Compatível com a ISO 9001, MPS.BR nível C, e CMMI nível 3. Simples de entender, porém difícil de aplicar.

Sistemas Adaptativos Complexos – CAS: É um sistema formado por uma rede dinâmica de agentes atuando em paralelo, agindo e reagindo constantemente ao que os outros agentes estão fazendo. O controle de um CAS tende a ser disperso e descentralizado. Os “agilistas” consideram o desenvolvimento de software como um CAS.

Uma metodologia pode ser considerada ágil quando é:
  • Incremental: liberar pequenas versões em iterações de curta duração;
  • Colaborativa: cliente e desenvolvedores trabalhando juntos em constante comunicação;
  • Direta: O método em si é simples de aprender e modificar;
  • Adaptativa: Capaz de responder as mudanças até último instante.

Elementos do SCRUM

… → Product Backlog → Reuniões de Planejamento → Sprint Backlog → Burndown → Impedimentos → Product backlog → ...

Papéis
  • Product Owner: Dono do Produto, conhece o negócio e representa demais stakeholders. Estabelece e comunica a visão do produto. Cria o release plan e o product backlog inicial. Monitora o projeto com metas de ROI. Responde e apóia o Scrum Team para sanear dúvidas sobre requisitos. Decide quando serão liberadas as versões do produto. Atualiza e prioriza continuamente o product backlog para assegurar que as funcionalidades mais valiosas são produzidas primeiro. É o Gerente de Produto assumindo parcelas do gerente de Projetos.
  • Scrum Master: Semelhante ao GP, responsável por liderar o time. Acompanha o progresso do trabalho, verifica se está sendo seguidos os padrões e inspeciona as implementações.
  • Scrum Team: Time multi-fucional que reúne todas especializações necessárias para implementar segmentos completos de software a cada sprint. Identifica impedimentos e reporta ao Scrum Master. Realiza a reunião diária de Daily Scrum para garantir comunicação plena do time e sincronismo de tarefas, de pé, no máximo 15 minutos. Pode lançar mão de quaisquer recursos disponíveis para se adaptarem a circunstancias não previstas.
  • Stakeholder: São todos os interessados no software em desenvolvimento a começar por clientes, usuários finais, equipe de marketing e vendas, scrum master, management e outros. São representados pelo dono do produto que deve conhecer o interesse e coletar ideias de todos para contruir o Product backlog.
  • Management: corrensponde ao grupo diretor, que provê fundos ($$) para o projeto ou responsável em última instância.

Detalhamento dos Elementos do SCRUM

→ Product Backlog
Este documento contém todos os itens que devem ser implementados no produto alvo. É atualizado sempre que houverem novas demandas para o produto alvo. Cada item deve ser estimado para determinar o tempo necessário para desenvolvê-lo.

→ Reuniões de Planejamento
Define-se os itens do Product Backlog que serão adicionados no sprint atual. Planeja-se o total de horas da equipe destinada ao sprint. A estimativa de cada item do Product Backlog diminui o total de horas planejada para o Sprint, o planejamento é encerrado quando acaba-se o total de horas que a equipe tem disponível, normalmente 40 horas. Não faz hora extra, planeja fazer apenas o possível para a semana ou dia.

→ Sprint Backlog
É a lista de itens adicionados no sprint atual, sprintpost-it grande e colado na coluna Backlog do quadro. Caso o item seja complexo para desenvolver deve-se detalhar em atividades menores através do post-it médio. Pode-se ainda ir classificando os post-it em execução, os feitos, os que faltam e os impedimentos.

→ Impedimentos
Tarefas não relacionadas com o desenvolvimento do sprint que devem ser descritas na coluna “BurnDown”. Exemplos: Reunião com clientes, suportes...

→ Burndown
Aqui cola-se os post-it com os impedimentos.

*** Sprint: um sprint é uma iteração de duas semanas a 30 dias. Quem atualiza os post-it no quadro são os próprios desenvolvedores, analistas... assim fica visível para todos o que cada um está fazendo e acredito que também motive as pessoas a trabalharem mais para terminarem logo os itens e irem tirando de “em execução” e “mostrar serviço”. No lado esquerdo do post-it marca-se a estimativa e no lado direito o tempo realizado. No verso do post-it pode-se citar os passos de testes. No final do projeto tirar foto e remover os post-it.

Críticas sobre métodos ágeis:
  • Falta estrutura e documentação realmente necessária.
  • Requer desenvolvedores experientes e disciplinados.
  • Costumam resultar em desenho insuficiente.
  • Requer mudança cultural muito grande.
  • Dificultam negociações contratuais.
  • Dificultam estimativas de esforços, custos e prazos para projetos maiores.
  • Mostram dificuldades de tratamento dos requisitos funcionais e não funcionais.


Método XP

O mais conhecido e radical dos métodos ágeis, Extreme Programming.

Jogo do Planejamento: Os desenvolvedores estimam esforço, o cliente define escopo e prazo.
Liberações pequenas: Iterações duram de 2 a 3 semanas.
Metáfora: A forma do produto é definida por uma metáfora.
Desenho Simples: O código resultante passe em todos os testes, comunique tudo que os programadores querem comunicar..
Desenvolvimento dirigido por testes: Testes de unidades são escritos o tempo todo.
Programação em pares: Todo o código é escrito conjuntamente por 2 programadores na mesma estação de trabalho com papéis de piloto e navegador.
Integração contínua: Sempre integrado.
Propriedade coletiva: Todo programador pode alterar qualquer código.
Cliente Local: representante do cliente disponível durante o tempo todo.
Semana de 40 horas: Horas extras são proibidas.
Espaço aberto: A equipe trabalha em baias em uma única sala.
Regras adaptáveis: A equipe se compromete com as regras anteriores, mas pode alterá-las sempre que necessário.
Medir a velocidade do projeto: Medir o progresso.
Trocar as pessoas com frequência: trocar entre as diversas partes do projeto.
Reunião diária de pé.
Plano de liberações: Plano detalhado de cada iteração.
Padrões de codificação.
Otimizações: Otimizar no final do projeto.
Protótipos: Desenvolvimento de protótipos.

Engenharia de Software - Parte IV - GP

Continuando a série, aula sobre gerenciamento de projetos.

Projeto: Segundo PMI (Project Management Institute), um projeto é um esforço temporário (início, meio e fim) empreendido para criar um produto, serviço ou resultado exclusivo, único. A elaboração é progressiva, o escopo muda no decorrer do projeto.

A gestão de projetos é uma atividade complementar (guarda-chuva) estando presente em todas as fases do projeto. Envolve planejamento, monitoração e o controle do pessoal.

A Gestão de Projetos surgiu para melhorar, organizar os processos dentro dos projetos.

4P → Pessoas, Projeto, Processo, Produto

As pessoas executam processos dentro de um projeto para chegar a um determinado produto.

As 9 áreas do conhecimento GP
Escopo, Comunicação, Tempo, RH, Integração, Riscos, Qualidade, Aquisições e Custos. Essas áreas normalmente estão dentro de 5 fases maiores chamadas “Genéricas”.

5 fases Genéricas presentes nas 9 áreas de conhecimento da Gestão de Projet

  • Inicialização

    • O que fazer? Quem é o GP? Qual equipe? Expectativa de resultado (cliente)? Qual o ROI? Está alinhado à estratégia da empresa?

  • Planejamento

    • É um processo de aprendizado com o cliente, seu valor está mais no seu exercício do que no plano que ele gera.

  • Execução

    • Fase que toma mais tempo no cronograma, construção do sistema.

  • Controle

    • Presente paralelamente as outras fases. Monitorar e intervir quando necessário.

  • Encerramento

    • Avaliação ROI; Reunião lições aprendidas; Ganhos Tecnológicos; Resultados;

  • Detalhamento das 9 áreas


    Escopo

    • 1 Planejamento: Coletar requisitos;

    • 2 Planejamento: Definir escopo;

    • 3 Planejamento: Criar EAP (Estrutura Analítica de Processo → WBS

    • 4 Controle: Verificar escopo;

    • 5 Controle: Controlar escopo;

  • Comunicação
    • 1 Inicialização: Identificar Stakeholders (partes interessadas → patrocinadores, cliente, governo, qualquer um que possa ser afetado pelo projeto);
    • 2 Planejamento: Planejar comunicações (Com quem vai falar, quando e de que forma);
    • 3 Execução: Distribuir informações;
    • 4 Execução: Gerenciar expectativas;
    • 5 Controle: Relatar desempenho;

  • Tempo

    • 1 Planejamento: Definir atividades mais detalhadas, elas já estão abstratas no WBS;

    • 2 Planejamento: Sequenciar atividades (quais precisam ser feitas primeiro para possibilitar as outras...);

    • 3 Planejamento: Estimar recursos (pessoas, tecnologias, servidores...);

    • 4 Planejamento: Estimar duração (por atividade, utilizar parâmetros de projetos anteriores se existirem);

    • 5 Planejamento: Desenvolver cronograma;

    • 6 Controle: Controlar cronograma;

  • RH

    • 1 Planejamento: Desenvolver plano de RH (matriz com habilidades dos colaboradores para saber os recursos que tem disponível para projeto, planejar treinamentos);

    • 2 Execução: Contratar/mobilizar equipe (mobilizar a equipe e caso necessário pode-se contratar novas pessoas);

    • 3 Execução: Desenvolver equipe (treinamentos se necessário);

    • 4 Controle: Gerenciar a equipe;

  • Integração: área central, consome cerca de 70% tempo do GP

    • 1 Inicialização: Desenvolver termo de abertura;

    • 2 Planejamento: Desenvolver Plano do Projeto;

    • 3 Execução: Orientar e gerenciar execução;

    • 4 Controle: Monitorar e controlar o trabalho;

    • 5 Controle: Controle integrado de mudanças;

    • 6 Encerramento: Encerrar Fase/Projeto (reunião de lições aprendidas...).

  • Riscos

    • 1 …? Faltou comentar este na aula.

  • Qualidade

    • 1 Planejamento: Planejar a qualidade (padrões de tela, requisitos bem feitos...);

    • 2 Execução: Garantia da qualidade (medir o processo, resultados);

    • 3 Controle: Controle da qualidade (acompanhamento do processo de garantia de qualidade, se está sendo feito);

  • Aquisições

    • 1 Planejamento: Planejar aquisições (o que comprar e de quem);

    • 2 Execução: Conduzir aquisições;

    • 3 Controle: Administrar aquisições (chegaram dentro do prazo, transporte adequado);

    • 4 Encerramento: Encerrar aquisições;
  • Custos


    • 1 Planejamento: Estimar custos (Salários, equipamentos, viagens...);

    • 2 Planejamento: Determinar Orçamento;

    • 3 Controle: Controlar custos;

  •  

Engenharia de Software - Parte III - Requisitos

É a capacidade do sistema ou descrição de algo que o sistema é capaz de realizar, para resolver um problema ou atingir um objetivo do usuário. São descritos em diferentes níveis de abstração.

  • Requisito não funcional: relacionado com o meio, confiabilidade, implícito, funcionalidades secundárias do sistema.
  • Requisitos funcionais: descreve funcionalidades que o sistema deverá ter.
3. Cite alguns problemas encontrados no processo de identificação de requisitos
Problemas na identificação de requisitos:
  • Falta de clareza;
  • Comunicação falha;
  • Erros de análise;
  • Descrição do requisito, ambiguidades;

Análise de Requisitos
  • Entender os requisitos específicos que precisam ser satisfeitos para construir software de alta qualidade.
  • Como se faz: requisitos de dados, funcionais e comportamentais são identificadas pela elicitação do cliente. O comportamento do software precisa ser representado.

Recomendações para descrição de requisitos
  • Utilizar termos que definem o grau de obrigatoriedade do requisito. Ex.: Deve, poderá, requer...
  • Evitar uso de jargões;
  • Descrição clara;
  • Evitar duplicidade de informações;
4. O que é engenharia de requisitos?
Engenharia de Requisitos
  • Conjunto de técnicas empregadas para levantar, detalhar, documentar, validar e gerenciar os requisitos de um produto.
  • É o passo essencial para o desenvolvimento de um bom produto.
  • O principal artefato da engenharia de requisitos é o Modelo de Problema.

5. O que deve ser descrito no modelo do problema?
Modelo de Problema
  • Funcionalidades: o que o produto deverá fazer?
  • Interfaces externas: como o produto interage com as pessoas, hardware e outros sistemas?
  • Desempenho: qual tempo de resposta?
  • Outros atributos: quais as considerações sobre confiabilidade, segurança, portabilidade?
  • Restrições impostas pela aplicação: existem padrões ou limites a serem obedecidos?

A equipe (todos) do projeto é responsável por desenvolver o modelo de problema porque apenas o desenvolvedor e cliente não são suficientes, os clientes não entendem o processo de software e o desenvolvedor não entende a área de aplicação.

Como garantir que especificamos um sistema que atenda as necessidade e satisfaça às expectativas dos clientes? Não existe resposta infalível mas um processo de engenharia de requisitos bem feito é a melhor solução atual.
Engenharia de Requisitos é um trabalho que exige boa e intensa comunicação entre o engenheiro e o cliente, é composto pelas seguintes fases:
  • Estudo da viabilidade: verifica se vale a pena ou não gastar tempo e esforço com o sistema proposto, verificar se o sistema contribui para os objetivos da organização, verifica se o sistema pode ser implementado usando a tecnologia atual e dentro do orçamento, se o sistema pode ser integrado a outros.
  • Elicitação: perguntar ao cliente quais os objetivos do sistema, o que precisa ser conseguido, como o sistema se encaixa nas necessidades de negócio e como o sistema vai ser usado no dia a dia. Identificar os fatos relacionados aos requisitos. Criar cenários de uso (Use Case). Identificar o ambiente técnico onde o sistema vai ser colocado. Avalia viabilidade técnica de cada requisito detalhadamente.
    • A elicitação de requisitos gera uma declaração da necessidade e viabilidade, uma declaração delimitada de escopo do sistema, uma lista de usuários que participam, uma descrição do ambiente técnico do sistema, uma lista de requisitos e as restrições do domínio de cada um, um conjunto de cenários, protótipos desenvolvidos.
    • Técnicas
      • Entrevistas
      • Questionários
      • Casos de Uso
      • Brainstorming: reunir pessoas em uma sala e ….
    • Sempre perguntar
      • O que? Por que? Como?
      • Organize as respostas e observe, seja humilde para aprender.
  • Análise e negociação: habilidade do analista negociar com cliente e retirar requisitos que não sejam necessários e também adequar ao valor (custo) e tempo (prazo) disponibilizado. Também define-se prioridade dos requisitos (essencial, obrigatório, desejável...).
    • Verificar se:
      • cada requisito está consistente com objetivo global do sistema?
      • Requisito está no nível de abstração adequado, de fácil entendimento?
      • Requisito é realmente necessário?
      • Requisito tem atribuição (fonte, pessoa) associada?
      • Requisito é limitado e não ambíguo, ou seja, delimita bem, evita que o cliente pessa mais coisas depois.
      • Algum requisito conflita com outro?
      • Requisito é realizável no ambiente técnico do sistema?
      • Requisito pode ser testado quando estiver implementado?
  • Especificação: é um documento escrito, combinando descrições em linguagem natural e modelos gráficos (ex: casos de uso).
  • Modelagem do sistema: processo onde se elabora Modelo ER, modelo de classes, dizendo como o sistema vai ser estruturado → especificação visual tanto para o programador quanto para cliente, mas mais para o programador.
  • Validação: a especificação é avaliada quanto a qualidade através da revisão onde cada requisito é questionado, além de repetir as questões da fase de análise e negociação, os seguintes tópicos:
    • requisitos de desempenho, comportamento e características operacionais estão claramente definidos?
    • Foi criado um índice da especificação? Código para cada requisito (RF1, RNF2, RN1...)
    • O requisito está limitado em termos quantitativos?
    • Que outros requisitos se relacionam com este requisito?
    • Pode-se rastrear o requisito em qualquer modelo criado do sistema?
    • O requisito pode ser rastreado até os objetivos globais do sistema?
    • O requisito viola alguma restrição do domínio?
  • Gestão: é o processo de mudanças de requisitos durante o processo de engenharia de requisitos e o desenvolvimento de sistema. Os requisitos são, inevitavelmente, incompletos e inconsistentes e com isso novos requisitos acabam surgindo durante o processo, à medida que as necessidades de negócio mudam e uma melhor compreensão do sistema é desenvolvida. Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios.
    • É necessário planejar:
      • Identificação requisitos;
      • Processo de mudança de requisitos;
      • Políticas de rastreabilidade: quantidade de informações mantidas sobre as relações entre os requisitos;
      • Apoio de ferramenta CASE;

Requisitos de alta qualidade são claros, completos, sem ambiguidades, implementáveis, consistentes e testáveis. Qualquer requisito que não apresenta estras características poderá ser problemático ao projeto.

IEEE → I3E → Instituto de Engenheiros Eletrônicos e Eletricistas

Instituto responsável por ditar normas e padrões sobre ciclo de vida de software, métricas etc. Normalmente estas normas estão em Inglês, raramente aparece algum em espanhol.
IEEE 830 → Atributos de um bom documento de requisitos:
    • Correto: os requisitos são aqueles que o sistema efetivamente deve atender.
    • Sem ambiguidades: única interpretação.
    • Completo: todos requisitos estão identificados, bem como respostas do sistema para todas situações de utilização.
    • Consistente: todos requisitos estão de acordo com especificações superiores.
    • Verificável: uma pessoa ou sistema atestar o cumprimento de cada requisito listado.
    • Modificável: qualquer requisito listado pode ser alterado sem impactar nos demais requisitos (ortogonais).
    • Trançável: é possível relacionar ele com as telas.

Engenharia de Software - Parte II - Ciclos de Vida

Continuando a série de Engenharia de Software, trabalho feito na aula em grupo (Bolívar, Jonas, Sidnei e Dinamar), em seguida o que consegui anotar dos outros grupos, no final links relacionados by Google.

Método RUP – Ciclo de vida do Software
Conhecida como metodologia que siga uma formalidade bem definida, a RUP (Rational Unified Process) enfatiza o rigor nas premissas, propostas e preza por uma documentação detalhada em todas as fases do desenvolvimento. Usa a abordagem orientada a objetos OOA e é projetado e documentado utilizando a notação UML para ilustrar os processos em ação.

A vantagem porém é o fato de ser amplamente customizável, sendo possível adaptar ele para projetos de qualquer escala, bastando eliminar algumas etapas – dependendo do tipo de projeto então basicamente os responsáveis pelo gerenciamento do mesmo definem os critérios que podem tornar os controles mais rigorosos ou não. Também traz riqueza de conhecimento, sempre atualizado para estação de trabalho do desenvolvedor, na forma de um instrutor eletrônico.

Entre suas desvantagens podemos citar que é um processo pesado um função da grande documentação e por isso é preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos.

Sua estrutura está dividia em Disciplinas (eixo horizontal) e fases (eixo vertical). Na fase concepção há muito trabalho de modelagem do negócio, definição de requisitos e início do gerenciamento de projeto, estudo do ambiente. Na fase seguinte, fase de elaboração, ainda são analisados requisitos e modelo de negócio mas o principal é o início da análise, da construção, da implementação e testes. A terceira fase é chamada de Construção e nela é feita a maior parte da implementação, testes e gerenciamento de mudanças, após está fase chegamos a fase final, Transição, nela há grande participação do gerenciamento de projeto, término configuração e gerenciamento do ambiente, muito trabalho de desenvolvimento e término da implementação e testes.


O RUP unifica toda equipe de desenvolvimento de software otimizando a produtividade de cada membro da equipe, disponibilizando as melhores práticas derivadas de projetos passados para ajudar no desenvolvimento de um produto com qualidade, dentro do orçamento e prazo possível.