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.


Pelé na Campanha BM&FBOVESPA


Relacionado

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.

Videos CTG Tropeiros do Buricá!

Olá pessoal!

Mês de Setembro sempre bem agitado no CTG, to saindo agora pra ensaiar, resolvi postar link para alguns videos das nossas apresentações, ainda não tem nenhum de Malambo nem de Chula mas quem sabe daqui alguns dias alguém filme a gente :D



Mais...
http://www.youtube.com/watch?v=9IKuTdm-twk
http://www.youtube.com/watch?v=lAz8Nh-oZYA
http://www.youtube.com/watch?v=gkSD_FstTC8
http://www.youtube.com/watch?v=Hx5v2rKeIko

Quem quiser nos assistir, vamos apresentar segunda-feira na Argentina, Festa dos Amigos em Oberá, dia 12 no CTG Tropeiros, almoço galeto massa e muitas sobremesas, também no dia 19, 1 tonelada de carne, costelão show de bola!

Abraços e tchau que estou atrasado!