Sucesso Profissional Começa na Infância (com legendas)

 

É bom começarmos ensinar nossos pequenos sobre estes princípios, o sucesso deles depende de nós. Recomendo fortemente a leitura do artigo Aprendendo Enquanto Somos Jovens e outros disponiveis no site http://www.cerebromente.org.br/indexge.htm.

Solução de Problemas com Heurística - Desafio 8 Rainhas

Olá amigos!

Como prometido no post anterior, o programa para encontrar uma solução para o desafio das 8 rainhas foi concluído com sucesso utilizando conceitos de Inteligência Artificial, neste caso Heurística, que busca encontrar uma solução para determinado problema sem que tenhamos que testar todas as possibilidades, ou seja, busca um atalho através de escolhas inteligentes. Muito utilizado para problemas em que não é necessário encontrar a melhor solução e que o número de possibilidades seja tão grande que não é viável testar todas possibilidades pois levaria muito tempo com a capacidade de processamento atual.

O programa foi feito em Java no NetBeans, dividido em dois arquivos para ficar mais organizado e fácil de entender, o segundo objetivo foi parcialmente alcançado :).

Abaixo a função principal (main) onde é chamado as outras funções e fica fácil de entender como ele funciona.



Agora a classe que implementa as funções chamadas na Main.

Isaac Asimov prevendo o impacto da Internet (português)

O Grande Axioma da Vida

Se você não mudar quem você é, você continuará tendo o que sempre teve. “Fazer as coisas certas e não certas coisas” "Para ter mais amanhã, você precisa ser mais do que é hoje"


Há uma história muito interessante, chamada "O Tesouro de Bresa", onde uma pessoa pobre compra um livro com segredo de um tesouro.

Para descobrir o segredo, a pessoa tem que decifrar todos os idiomas escritos no livro. Ao estudar e aprender estes idiomas começam a surgir oportunidades na vida do sujeito, e ele lentamente (de forma segura) começa a prosperar.

Depois ele precisa decifrar os cálculos matemáticos do livro.

É obrigado a continuar estudando e se desenvolvendo, e a sua prosperidade aumenta. No final da história, não existe tesouro algum - na busca de segredo, a pessoa se desenvolveu tanto que ela mesma passa a ser o tesouro.

O profissional que quiser ter sucesso e prosperidade precisa aprender a trabalhar a sim mesmo com muita desciplina e persitência. Vejo com frequência as pessoas dando um duro danado no trabalho, porque foram preguiçosas demais para darem um duro danado em si mesmas.

Os piores são os que acham que podem dar duro de vez em quando. Ou que já deram duro e agora podem se acomodar.

Entenda: o processso de melhoria não deve acabar nunca. A acomodação é o maior inimigo do sucesso!!

Por isso dizem que a viagem é mais importante que o destino.

O que você é acaba sendo muito mais importante do que você tem.

A pergunta importante não é "quando vou ter?", mais sim, "no que vou me transformar?".

Não é "quanto vou ganhar", mas sim "quanto vou aprender?".

Pense bem e você notará que tudo o que tem é fruto direto da pessoa que você é hoje. Se você não tem o suficiente, ou se acha o mundo injusto, talvez esteja na hora de rever esses conceitos.

O porteiro do meu prédio vem logo à mente. É porteiro desde que o conheço. Passa 8 horas por dia na sua sala, sentado atrás da mesa. Nunca o peguei lendo um livro. Está sempre assistindo à TV, ou reclamando do governo, do salário, do tempo. É um bom porteiro, mas em todos esses anos poderia ter se desenvolvido e hoje ser muito melhor do que é. Continua porteiro, sabendo (e fazendo) exatamente as mesmas coisas que sabia (e fazia) dez anos atrás. Aí reclama que o sindicato não negocia um reajuste maior todos os anos. Nunca consigui fazê-lo entender que as pessoas não merecem ganhar mais só porque o tempo passou. Ou você aprende e melhora, ou merece continuar recebendo exatamente a mesma coisa.

Produz mais, vale mais? Ganha mais. Produz a mesma coisa? Ganha a mesma coisa. É simples. Os rendimentos de uma pessoa raramente excedem seu desenvolvimento pessoal e profissional.

Às vezes alguns têm um pouco de sorte, mas na média isso é muito raro. É só ver o que acontece com os ganhadores da loteria, astros, atletas. Em poucos anos perdem tudo. Alguém certa vez comentou que se todo o dinheiro do mundo fosse repartido igualmente, em pouco tempo estaria de volta ao bolso de alguns poucos. Porque a verdade é que é difícil receber mais do que se é.

Como diz Jim Rohn, no que ele chama do grande axioma da vida: "Para ter mais amanhã, você precisa ser mais do que é hoje". Esse deveria ser o foco da sua atenção.

Não são precisos saltos revolucionários, nem esforços tremendos repentinos. Melhore 1% todos os dias (o conceito de "Kaizen"), em diversas áreas da sua vida, sem parar. Continue, mesmo que os resultados não sejam imediatos e que aparentemente/superficialmente pareça que não está melhorando.

Porque existe, de acordo com Rohn, um outro axioma: O DE NÃO MUDAR.

Se você não mudar quem você é, você continuará tendo o que sempre teve.

"Fazer as coisas certas e não certas coisas"

Texto: Autor desconhecido.
 

Sistemas Especialistas

Inteligência Artificial – Aula 2010-10-13 – Professor Helmuth Grossmann

Sistemas Especialistas

São sistemas com foco em uma área especifica, busca tomar uma decisão igual ou próxima ao de um especialista da área. São comuns em sistemas do mercado financeiro, controle de consumo cartão crédito...

Podem ser de dois tipos:
  • Baseados em Casos (SEBC): Possui um banco com diversas situações e suas soluções, ao resolver novos problemas busca por um caso similar ou igual para determinar a solução.
  • Baseados em Regras (SEBR): Aplica algumas regras para resolver a situação.

Sistemas especialistas possuem uma base de conhecimento e um sistema/motor de inferência (metodologia para encontrar solução) separados, podem tomar decisões lógicas sob imprecisão ou com falta parcial de informações. Para construir um SE é necessário primeiro sistematizar o conhecimento do especialista (criar a base de conhecimento), após permitir que o sistema aprenda (inserir novos casos ou regras) e ter um bom motor de inferência para localizar um caso similar ou (se não encontrar caso ou não usar casos) aplicar as regras.

Os especialistas devem resolver problemas difíceis, explicar os resultados, aprender, reestruturar seu conhecimento e determinar as características relevantes de seu conhecimento.

O primeiro sistema especialista (SE) foi o DENDRAL, em 1965, automatizava raciocínio sobre estruturas químicas, usado meio acadêmico. Depois (1976) veio o MYCIN, pioneiro no uso de fatores de certeza, conseguia ultrapassar um clínico de perícia médica no diagnóstico de pacientes com meningite utilizando critérios (regras) para identificar 3 diferentes causas, este foi o software que deu impulso para investimentos nos sistemas especialistas. Em 1982 também ficou bastante conhecido o XCON, usado para configurar sistemas computacionais complexos. A partir dos anos 90 muitos SE's passaram a utilizar a lógica fuzzy, em busca de soluções mais precisas, rápidas e confiáveis, os SE's passaram também a utilizar soluções mistas com casos e regras.

Em Singapura, desde 1980, SE's são utilizados em setores bancários, financeiro, manufatura... no Japão sistemas com lógica difusa estão crescendo nos eletrodomésticos, na Alemanha são utilizados principalmente em indústrias pesadas. Nos EUA os SE's tem ênfase para o problema de “solução de negócios” e sistemas “ativos”, sistemas colaborativos com ampla base de conhecimento e compartilhamento do mesmo, exemplo sistemas de suporte a equipamentos HP, Dell...

No Brasil podemos citar os SE's :
  • Análise de crédito bancário (Pereira, 1995);
  • Análise de hepatopatias crônicas (Vieira, 1996);
  • Análise química qualitativa de minerais (Fernandes, 1996);
  • Sistema de apoio ao diagnóstico de problemas em computadores (Grossmann, 2001);

Outros exemplos/possibilidades:
  • Cálculos de penas no sistema judiciário;
  • Prospecção e detecção de petróleo;
  • Manutenção de redes de energia;
  • Classificação de pisos cerâmicos (UFSC);
  • Análise da qualidade de amostras de milho;
  • Análise de motores de compressores;
  • Diagnóstico médico;
  • Cotações de seguros...

Bom pessoal, eu vou me dedicar a criar um SE para operações com análise técnica em bolsa de valores, é possível também criar com análise fundamentalista (não conheço muito), ainda não decidi se vou usar apenas com regras, com casos, misto (mais provável), com lógica fuzzy, redes neurais etc, ainda preciso estudar mais. Até!


Só no Brasil mesmo

KIT DO BRASILEIRO

*Vai transar?*
O governo dá camisinha.


*Já transou?*
O governo dá a pílula do dia seguinte.

 
*Teve filho?*
O governo dá o Bolsa Família..


*Tá desempregado?*
O governo dá Bolsa Desemprego.


*Vai prestar vestibular?*
O governo dá o Bolsa Cota.


*Não tem terra?*
O governo dá o Bolsa Invasão e ainda te aposenta.


*RESOLVEU VIRAR BANDIDO E FOI PRESO?*
Desde
de 1º/1/2010 O GOVERNO DÁ O AUXÍLIO RECLUSÃO?

*
esse é novo*   Todo presidiário com filhos tem direito a uma bolsa que, é de R$798,30 "por filho" para sustentar a família, já que o coitadinho não pode trabalhar para sustentar os filhos por estar preso.
 
Não acredita?

Confira no site da Previdência Social.


Portaria nº 48, de 12/2/2009, do INSS

(
http://www.previdenciasocial.gov.br/conteudoDinamico.php?id=22)

*Mas experimenta estudar e andar na linha pra ver o que é que te acontece!*


"Trabalhe duro, pois milhões de pessoas que vivem do Fome-Zero e do Bolsa-Família,  sem trabalhar, dependem de você"
Se vc é brasileiro passe adiante.
 Recebi por e-mail o conteúdo acima e resolvi compartilhar pois isso ai é uma verdade, tudo bem que tem muita miséria por ai, mas também tem muito malandro vivendo a custa dos outros, essas leis são tuqo que esses mer** pediram para o todo poderoso, quem trabalha e tenta construir capital sofre para conseguir alguma coisa, e quanto mais você tem, mais você paga pro governo, é complicado. O Brasil é uma país legal, tem muitos recursos e tal, mas essas coisas são complicadas e as vezes fico com vergonha de ser brasileiro, essa semana passou na bloomberg, os reportes dando risada que foi eleito um palhaço (Tiririca), e ainda levou mais 3 políticos juntos, nossa situação anda complicada... outro dia compartilharam um artigo no reader que também comenta sobre este assunto, vale a pena dar uma lida e refletir (http://www.mundogump.com.br/ai-que-saudade-do-macaco-tiao/). Até!

Engenharia de Software - Parte VI - Construção

Aula Engenharia de Software → 2010-09-24
Professor Cristiano

Práticas de Implementação → Programação → Desenvolvimento de Software → XP

XP → Técnicas pra desenvolver o software

A programação (Implementação → processo de escrita de uma programa baseado em uma especificação de projeto) veio antes da Engenharia de Software, Engenharia surgiu quando foi necessário criar sistemas comerciais e não apenas pesquisa para fins militares etc, foi quando os programadores não tinham o conhecimento das regras de negócio, ai foi necessário ter analistas, documentadores, testadores, suporte etc.

É muito importante ter um ambiente bom para se trabalhar durante a fase de implementação para que os programadores possam trabalhar da melhor forma, sem ter muitos problemas para resolver, um programador estressado faz um trabalho pior do que um bem humorado.

A melhor forma de implementar um software é utilizar uma série de incrementos e iterações. Isso é desenvolvimento incremental, ou seja, cada iteração do processo produz um novo incremento do software.

Modularidade: é um conceito fundamental para construção de software pois é mais fácil resolver um problema complexo quando ele é dividido em partes (módulos).

O custo de esforço diminui até determinado ponto utilizando modularidade, quando se transforma tudo em módulos o custo pra pensar e programar as interfaces de cada módulo e na sua integração é muito maior do que se não tivesse dividido em módulos.

Análise → Planejamento → Implementação/Construção → Implantação

Dentro da Implementação existe um conjunto de práticas...
  • Checar pré-requisitos e pós-requisitos;
  • Definir informação a ser ocultada, entradas, saídas e tratamento de erros
  • Projetar testes para os módulos
  • Analisar aspectos de eficiência
  • Pesquisar algoritmos e estruturas de dados, encontrar o melhor.

APÓS ESSAS PRÁTICAS PRÉ-CODIFICAÇÃO, INICIA-SE O REAL DESENVOLVIMENTO, ONDE AINDA SÃO NECESSÁRIAS OUTRAS PRÁTICAS COMO:
  • Desenvolver e documentar cada unidade de software
  • Conduzir e documentar os testes unitários → os testes de unidade servem para avaliar a parte individual de um programa (funções e métodos de classe) para ter certeza de que cada elemento individualmente faça a coisa certa.
  • Atualizar a documentação, se necessário
  • Atualizar os requisitos para o teste de integração → quem vai testar vai partir dos requisitos e verificar se todos foram desenvolvidos, se durante o desenvolvimento algum deles foi modificado é importante alterar para que o testador não pense que foi desenvolvido errado.
  • Avaliar o código e os resultados dos testes de acordo com critérios.
  • Teste de Integração → verificar se os módulos não tem erros associados a interface que impossibilitem a comunicação/integração... normalmente se usa alguma ferramenta automática para testar integração. Pode se ter uma abordagem não-incremental para o teste onde o sistema é agrupado por completo e testado somente no final, pior forma de testar, ou uma abordagem incremental onde o sistema é agrupado em etapas, cada etapa desenvolvida é testada antes de passa para próxima facilitando assim o isolamento do erro.


Engenharia de Software - Diagramas de Visão Estrutural

Os Diagramas Estruturais servem para visualizar, especificar, construir e documentar os sistemas, permitem que todos tenham a mesma visão/idéia do sistema. Os principais (Estruturais) são o Diagrama de Classes, Diagrama de Objetos, Diagrama de Componentes e o Diagrama de Implantação.

O Diagrama de Classes é um dos mais usados, ele que define as características dos objetos. Pode ser usado para modelar os dados que o sistema vai manipular servindo de base para o modelo ER, também é usado para modelar as relações entre os objetos (dependências, associações, generalizações), definir atributos e métodos de cada objeto e a visibilidade dos mesmos (private, public, protected). Algumas IDEs permitem gerar o código a partir deste diagrama. Este aqui é básico pra desenvolver OO.

O Diagrama de Objetos consiste em uma instância do Diagrama de Classes, no qual para cada classe temos a instância do seu objeto com dados reais e seus relacionamentos, normalmente utilizado para esclarecer os relacinoamentos entre as classes e facilitar a modelagem de estruturas complexas de dados. Ajuda identificar possíveis problemas que poderão acontecer com o sistema funcionando pois ao se trabalhar com dados reais pode-se simular algumas rotinas. Bem interessante, vale a pena dar uma estudada.

O Diagrama de Componentes mostra a estrutura de componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam, até aqui não entendi nada Bolívar, ok, um diagrama de componentes mostra as dependências entre componentes de software, incluindo os classificadores que eles especificam (isto é, classes de implementação -> interfaces do sistema) e os artefatos que eles implementam (isto é, arquivos de códigos-fonte, arquivos de código binário, executáveis, scripts). Eu relamente não consegui pensar em alguma utilidade para este diagrama, ele basicamente mapeia os arquivos do teu sistema e os relacionamentos entre eles, tipo, arquivo index.html ligado com login.php ligado com verificalogin.php. Editando aqui: Achei um conteúdo na Net onde usam este diagrama para mapear os módulos e como eles estão relacionados, qual módulo depende de qual pra funcionar etc, achei legal.

O Diagrama de Implantação/Implementação, assim como o Diagrama de Componentes, mostra os aspectos de implementação física, a estrutura do sistema em tempo de execução (run-time), tipo, qual máquina vai rodar o sistema, por qual protocolo (TCP/IP) se dará comunicação, quais as interfaces (celular, tv, geladeira, caixa auto-atendimento banco...), achei tosco interessanta para mostrar pros clientes, não ajuda muito pra desenvolver, pouco utilizado também.

Referências: Melo, Ana Cristina. Desenvolvendo Aplicações com UML. Rio de Janeiro: Brasport, 2002.

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.

Engenharia de Software - Parte I

Boa noite pessoal!

Vou começar a postar minhas anotações das aulas aqui no meu blog, to sem assunto pra postar e isso me parece interessante, também me obriga a dar uma organizada e revisada nas anotações e facilita meu estudo depois (este é raro). Este semestre estou fazendo Engenharia de Software, Inteligência Artificial e Programação Comercial III (Java), pra começar vamos pra Engenharia de Software que é só teoria, segue anotações da primeira aula.

Aula 1 -Engenharia de Software – Prof. Leila

Fábrica de Software:
Interessados: Clientes, Donos, Colaboradores, Sociedade, Governo, Fornecedor, Parceiros.
Unidade Organizacional: Parte definida de uma organização que implanta um ou mais processos.
Equipe: Conjunto de pessoas trabalhando conjuntamente para atingir um objetivo em comum.
Papéis: Conjunto de competências e responsabilidades desempenhadas. Cargos.
Maturidade das Organizações: Conjunto de competências: gestão, resultados.
Sintomas de organizações imaturas: projetos não definidos claramente; pessoas sem treinamento; não existe planos claros de recrutamento, avaliação de desempenho e remuneração; as ferramentas utilizadas não ajudam a resolver problemas;  procedimentos e padrões quando existem são definidos de forma burocrática;
Processo: Conjunto de atividades que transforma entradas em saídas.
PDCA (Plan->Do->Check->Action->Plan...)
Prejuízos da imaturidade: Produtos de baixa qualidade; hábito de assumir compromissos não realistas;...
Forças caóticas: Pressão e prazos não deixa tempo para reflexão;  as pessoas acreditam que a solução pode estar em uma pessoa ou uma ferramenta e pode bloquear o pensamento racional...
Riscos: Deficiência de pessoal; Prazos e orçamentos irrealistas; desenvolvimento dos requisitos errados; desenvolvimento de interfaces de usuário erradas; embelezamento inútil; fluxo contínuo de alteração nos requisitos; deficiências de componentes de origem externa; deficiências em tarefas realizadas por terceiros; deficiências de desempenho em tempo real; forçar os limites;
Erros
    -Clássicos: erros repetidos;
    - Relativos a produto: defeitos na sua definição, introduzindo características no decorrer do projeto interessantes mas dispensáveis;
Software de Qualidade
    - Atender as expectativas do cliente;
    - Robustez / Confiabilidade;
    - Usabilidade -> experiência do usuário;
    - Segurança;
    - Manutenção;
Mitos de Software
    - Crenças sobre o software e sobre o processo utilizado para construí-lo.

EXERCÍCIOS

Descreva algumas características de uma organização imatura.
Os projetos não são claramente definidos, o cliente não sabe a quem recorrer, os próprios colaboradores não sabem o que fazer, não possui processos bem definidos.  A empresa não trabalha RH da forma correta, não realiza treinamentos, não faz avaliações de desempenho e não possui banco de talentos ou procedimentos para recrutamento.

Explique com suas palavras quais são os principais prejuízos de uma organização imatura?
Os produtos ou serviços entregues são de baixa qualidade, clientes e demais partes interessadas ficam insatisfeitos, colaboradores desmotivados e estressados no trabalho, assumem compromissos que nem sempre podem cumprir e costumam repetir erros.

Explique resumidamente os problemas que culminaram na crise do software?
Resumidamente, as estimativas de prazos e custos eram frequentemente imprecisas, faltava dedicar tempo para coletar dados. O desenvolvimento era iniciado sem conhecer exatamente o que seria necessário para o sistema deixando o cliente insatisfeito com o resultado, a qualidade do software era muito baixa, havia muita dificuldade em manter o software após desenvolvido.

O que é a crise do software?
Surgiu nos anos de 70 pra expressar as dificuldades existentes na área de desenvolvimento de software. A evolução rápida do hardware e aumento da procura levou a ter muitos clientes e a complexidade dos softwares se tornou maior, assim, muitos problemas surgiram e o período acabou ficando conhecido como a crise do software.

Quais foram as principais causas da crise do software?
As próprias características do software, software não se desgasta, mas se deteriora. Falhas das pessoas responsáveis pelo desenvolvimento, programadores com pouca experiência, resistência à mudança, gerentes sem experiência, falta de capacitação.

O que podemos fazer hoje para conter a crise do software?
Estudar muito, dar treinamento adequado às equipes de desenvolvimento, desde os gerentes até analistas, suporte, equipe de testes (homologação) e treinamento. Ter os processos definidos claramente para toda equipe, atenção especial a treinamentos específicos em gestão de pessoas para gerentes, conhecimentos sobre nova geração, ambiente de trabalho, ADP, flexibilidade de horários entre outros pontos que são considerados importantes.

O que são mitos de software?
São crenças sobre o software, sobre os processos de desenvolvimento, normalmente contém algumas verdades e muitas pessoas acreditam mas na realidade acabam passando informações errôneas e gerando confusão.

Quantos e quais são os tipos de mitos de software?
Gerência, Administrativos e Clientes... acredito que eram esses :D

A crise de software existe até os dias atuais? Justifique (pessoal).
Acredito que muitas empresas de pequeno porte ainda sofrem com essa realidade, normalmente por dificuldade em aceitar mudanças por parte dos gerentes. Também ainda há muitos “sobrinhos” ou mesmo programadores free lancers que desenvolvem programas/sites sem ter conhecimento necessário e acabam passando por todos os problemas comuns existentes durante o período da crise de software, na realidade acredito que estes problemas sempre existirão enquanto a área de desenvolvimento não tiver alguma regulamentação mais forte que impeça este tipo de atividade e force as empresas a adotarem algum padrão, hoje é tudo liberado (que bom, ou não). Essa regulamentação não é feita porque a um consenso entre as pessoas da área que vários dos melhores profissionais não tem formação acadêmica/técnica e também vários não são adeptos de padrões, ao menos na parte de programação, mas é comprovado que a qualidade do software entregue aumenta muito nos projetos que utilizam ao menos alguma “boa prática” já criada e isso acaba sendo o diferencial nos produtos das empresas.