Convite para o Enecomp 2013

Extreme programming

 

O extreme programming é um método ágil utilizado por pequenas e médias equipes, que trabalham em parceria com o cliente para que todo o projeto seja desenvolvido de acordo com os gostos e as necessidades do mesmo evitando a perca de tempo com a implementação de funções que não seriam utilizadas posteriormente. O extreme programming utiliza de valores para se obter o melhor resultado possível, como o feedback, que proporciona ao cliente o contato com o software desenvolvido mantendo o projeto sempre ao gosto do cliente; a simplicidade, onde busca trabalhar com implementações simples, claras e que realmente vão ser úteis ao cliente; a comunicação face-a-face, que é usada constantemente pelas equipes para saber se o cliente está gostando, se tem dúvidas, se é necessário alguma alteração; e coragem, pois suas   premissas básicas contrariam os métodos de desenvolvimento atuais.

Vantagens:

·         Produção rápida de protótipos;

·         Feedback frequente do cliente;

·         Incentiva a experiência de design;

·         Processo iterativo;

·         Aumento da confiabilidade do sistema;

·         Alta produção de código;

·         Código de qualidade.

Desvantagens:

·         Problemas de escalabilidade;

·         Mais focando nos resultados;

·         Imprevisível;

·         Maior sobrecarga;

Necessário desenvolvedores experientes.

Especificação de requisitos

A especificação de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados.

Podemos entender requisito como uma função, restrição ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do sistema. 

Os requisitos podem ser especificados como funcionais ou não-funcionais:

Funcionais: descrevem as funcionalidades do sistema desejadas pelos clientes, ou seja, o que se espera que o software faça;

Ex.:

·         O sistema deve possibilitar o cadastramento dos dados pessoais dos clientes;

·         O sistema deve emitir relatórios gerenciais;

Não-funcionais: São as qualidades e restrições globais do sistema relacionados com manutenção , uso, desempenho, custo , interface, etc.

Ex.:

·         Tempo de resposta do sistema não deve ultrapassar 10 segundos;

·         Software deve ser operacionalizado no sistema Windows;

O banco de dados usado deverá ser o Oracle.

RUP

Processo Unificado da Rational (RUP)

O Processo Unificado da Rational é um processo de engenharia de software criado para apoiar o desenvolvimento orientado a objeto e tem por objetivo cumprir um cronograma para que se obtenha um software que atenda às necessidades do usuário, que seja entregue a tempo e sem maiores custos do que o previsto. O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcançadas. O desenvolvimento de software é dividido em quatro fases: fase de concepção, fase de elaboração, fase de construção e fase de transição. Detalhes sobre as fases:

Fase de concepção: abrange as tarefas de comunicação com o cliente e planejamento, onde se avalia os possíveis riscos, as estimativas de custo e prazos, estabelece as prioridades, levantamento dos requisitos do sistema e análise.

Fase de elaboração: abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica.

Fase de construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.

Fase de transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

Modelos de Processos de Software

  Modelo cascata ou clássico

O modelo cascata foi projetado para aplicação em desenvolvimento de software. As etapas do modelo cascata seguem uma sequencia, onde uma etapa só começa quando a outra termina. Das fases do processo em cascata temos: Análise e definição dos requisitos, projeto do sistema, implementação, teste do sistema e manutenção.

A análise e definição dos requisitos consiste na definição dos serviços que devem ser fornecidos, limitações e objetivos de forma que esses requisitos sejam úteis nas próximas fases. Logo após temos projeto de sistema, que por sua vez se subdivide em: estrutura de dados, arquitetura de software, detalhes procedais e caracterização das interfaces. A fase de implementação é onde ocorro a criação dos programas, e estes serão testados individualmente para depois passar pelo teste global. Terminada a codificação dá-se inicio a fase de testes onde é observado se todos os erros foram solucionados e se os resultados obtidos  são satisfatórios, e finalmente chega-se a fase de manutenção que consiste na correção de erros que não foram previamente detectados. Todas as fases ao serem concluídas são documentadas, como se pode observar no esquema abaixo:

Vantagens:

·         Torna o processo de desenvolvimento estruturado. 

·         Tem uma ordem sequencial de fases;

·         Todas as atividades identificadas nas fases  do modelo são fundamentais e estão na ordem certa.

Desvantagens:

·         Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;

·         Não suporta modificações nos requisitos;

·         Não prevê a manutenção;

·         Não permite a reutilização;

·         É excessivamente sincronizado;

·         Se ocorrer um atraso todo o processo é afetado;

·         Atraso na entrega do software.

  Modelo de Prototipação 

O processo de desenvolvimento prototipado procura entender e organizar as limitações do Modelo de Cascata, para melhor definição dos requisitos do sistema tendo como ideia eliminar a política de “congelamento” de requisitos antes do projeto do sistema, com base no conhecimento dos requisitos do sistema, através de um protótipo.

O desenvolvimento desse protótipo é compreendido em analise de requisitos, projeto, codificação e testes.

Vantagens:
Conhecimento prévio do sistema;

Possibilidade de correção mais cedo;

Rápida entrega do sistema;

Especificação, desempenho e implementação integrada.

Desvantagens:
Alguns de seus requisitos não aparecem na espeficicação;

Requisitos onde não ser testados de forma adequada.

  Modelo Espiral

Baseado em 1988, um modelo formado por ciclos, uma organização de atividades em espiral. Sua dimensão vertical representa o custo acumulado na realização das etapas e a dimensão angular representa o avanço do desenvolvimento ao longo das etapas.

A cada ciclo inicia com a identificação dos objetivos e as diferentes alternativas para atingir seus objetivos, assim como as restrições impostas. O próximo passo no ciclo é a avaliação das diferentes alternativas com base nos objetivos fixados, definindo também incertezas e riscos. A seguir o desenvolvimento de estratégias permite resolver ou eliminar incertezas levantadas anteriormente (podendo envolver atividades de prototipação, simulação, avaliação de desempenho entre outros). Por fim, o software é desenvolvido e o começa o planejamento dos próximos passos e assim resolvidos.

Uma das principais características deste modelo é que cada ciclo é encerrado por uma atividade de revisão, onde tos os produtos do ciclo são avaliados ,incluindo o plano para o próximo ciclo.

  Modelo Incremental

O Modelo Incremental é uma estratégia de planejamento em que várias partes do sistema são desenvolvidas em paralelo e integradas quando completas. Não implica, requer ou pressupõe desenvolvimento iterativo ou em cascata. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única.

Vantagens:

·            As versões são fornecidas após cada iteração do modelo incremental;

·            O Modelo Incremental inclui o uso do software pelo usuário para que as mudanças sejam feitas de acordo com o mesmo;

·            É flexível e fácil de gerenciar processos mais administráveis e fazer um software melhor com uma melhor estrutura;

·            Os testes são simples, entre outros.

Desvantagens:

·            Cada fase de uma iteração é rígida e não se sobrepõem uns aos outros;

·            Podem surgir problemas relativos à arquitetura do sistema, porque nem todos os requisitos estão reunidos na frente de todo o ciclo de vida do software;

·            O modelo Incremental precisa ser relativamente pequeno.

  Modelo iterativo

Uma iteração representa um ciclo completo de desenvolvimento, em cada fase podem ocorrer várias iterações. Cada fase e iteração objetiva redução de riscos e funcionam como um marco do progresso. Esse marco define um ponto para avaliar o alcance das metas e se o projeto deve ser reestruturado por algum motivo para o prosseguimento.

Vantagens:

·            Baseia-se fortemente na participação e uma boa comunicação entre desenvolvedores e usuários.

·            Há um grande envolvimento do utilizador e do cliente.

·            Os resultados mostrados permitirá que os usuários tenham confiança em um bom resultado;

·            Os riscos podem ser melhor administrados por pequenos pedaços do sistema a serem desenvolvidos em pequenos espaços de tempo;

·            Alterações nos requisitos podem ser rapidamente incorporadas no processo de desenvolvimento, entre outros.

Desvantagens:

·            Durante o processo de desenvolvimento necessita-se adaptar e refinar o sistema, com isso pode ser que no final saia totalmente diferente da ideia original;

Pode acontecer a continuação do sistema e aparição de muitos requisitos novos, dessa forma o sistema nunca irá terminar. Isso é chamado de aumento de escopo, entre outras.

  Modelo Formal

O modelo formal requer Clientes tecnicamente bem preparados, engenheiros de software com conhecimento profundo do negócio em questão. E as especificações devem ser bem consistentes, claras sem qualquer ambigüidade. Utiliza fortemente os modelos matemáticos nas especificações. Portanto recomendado para aplicação extremamente crítica. Os métodos formais têm um potencial tremendo para melhorar a clareza e a precisão da especificação dos requisitos e de encontrar erros importantes e sutis. O método formal tem uma sólida base matemática, dada tipicamente por uma linguagem formal de especificação. Essa base fornece um meio para definir precisamente noções como consistência e completeza, e mais relevantemente, especificação, implementação e correção.

  Modelo de Desenvolvimento Orientado a Reuso

A reutilização sempre foi utilizada por outras engenharias. Apenas nos últimos anos é que a engenharia de software começou adotar o reuso como uma abordagem prática no desenvolvimento de software.  A reutilização é o processo de incorporar em um novo produto: Código, Plano de Teste, Conhecimento Geral e Especificações de requisitos e projetos.

E.K.D

Enterprise Knowledge Development – (E. K. D)                                                 

É uma metodologia recente que auxilia em analisar, entender, desenvolver e documentar uma organização e seus componentes usando a Modelagem Organizacional, podendo envolver todas as áreas de uma organização, fazendo-a uma classificação dos requisitos para que a organização (composição) fique em sintonia com a empresa (negocio).

A modelagem organizacional traz grandes benefícios à engenharia de requisitos de software, à medida.

Que auxiliam o entendimento dos aspectos sociais, organizacionais, técnicos, jurídicos e econômicos.

(PADUA, 2002)

 Metodologia E. K. D

Na modelagem organizacional do EKD são tratadas algumas questões como:

· Estratégias do plano de negócios;

· Análise e definição dos conceitos e regras de negócio;

· Reengenharia dos processos de negócio;

· Planejamento de pessoal.

Tendo como objetivo “desenhar”  o modelo organizacional e obter o melhor entendimento para resolver problemas e desenvolver o conhecimento da organização.

 “A técnica de Modelagem Organizacional EKD facilita a compreensão do ambiente empresarial e é  conhecida como uma atividade valiosa para a engenharia de requisitos” Pádua (2001)

Pode se utilizar o mesmo, tanto em negócios já existentes ou em situaçoes futuras que possam vir a ocorrer no negocio.

Bubenko et al (2001),cita alguns benefícios tradizidos na utilizaçao de metodologia E.K.D:

· Compreender melhor o negócio;

· Facilitar a aprendizagem organizacional e a comunicação sobre questões essenciais;

· Auxiliar a compreender as capacidades e processos dentro da organização;

· Melhorar a comunicação entre usuários e desenvolvedores do sistema de informação;

· Desenvolver uma descrição estruturada do negócio

· Auxiliar os desenvolvedores do sistema de informação e usuários na determinação dos requisitos e objetivos do sistema;

· Estabelecer uma descrição dos objetivos, entidades, processos e requisitos que é mais consistente e completa do que uso desta descrição em forma de texto;

· Gerar uma base de documentos em computador (repositório de conhecimento) que pode ser usado para:

- Argumentar sobre o negócio;

- Discutir as mudanças e evolução do negócio;

- Traçar uma sequencia de componente e decisões que conduzem a várias implementações de decisões e componentes de sistema de informação.

O EKD tem alguns modelos que analisam a organização e suas exigências partir de perspectivas interrelacionadas que construirão o modelo da empresa segundo o aspecto representado por cada um dos Modelos,dos quais os mais conhecidos são: Modelo de objetivos; Modelo de Regras de negócio; Modelo de Processos de negócio; Modelo de Conceitos; Modelo de Requisitos e componentes técnicos; e Modelo de Atores e Recursos.

Sub-Modelos do Enterprise Knowledge Development – E. K. D.

Modelos de objetivos

Apresenta uma descrição do que a organização deseja alcançar, impedir ou evitar. O objetivo é mostrar pontos como: o caminho que a organização deve seguir, prioridades dos objetivos estabelecidos e qual o relacionamento dos objetivos com os problemas, ameaças e oportunidades encontrados na busca de suas realizações.

4.2.2        Modelo de regras de negócio

 Define e apresentar as regas de negócio. A consistência e formulação dessas regras dependem do que foi estabelecido no modelo de objetivos, esclarecendo questões do tipo:

· Quais regas afetam os objetivos da organização;

· Como cada regra do negócio está relacionada com os objetivos;

· Como os objetivos são apoiados pelas regras;

· Quais são as políticas declaradas.

4.2.3        Modelo de Processo de negócio

Definir os processos organizacionais, mostrar a forma de interação e manuseio das informações e materiais.

Outra finalidade desse modelo é apresentar quais são as entradas necessárias em termos de informação ou material. A elaboração do modelo de processo de negócios permite esclarecer:

· Quais são as atividades e processos reconhecidos na organização em concordância com as metas;

· De que forma os processos deveriam ser realizados e quais as informações necessárias.

4.2.4        Modelos de Conceitos

Deve incluir componentes pelos quais se pode descrever o conteúdo de diferentes conjuntos de informações e fluxos do processo de negócios, servindo como um dicionário, pois também define as entidades e os dados da aplicação sob um aspecto conceitual.

4.2.5        Modelo de atores e recursos

Define os tipos de atores e recursos envolvidos na atividade da empresa. Descreve como diferentes atores e recursos se relacionam uns com os outros e como ele se relacionam com os componentes do modelo de objetivos.

Atores e recursos podem ser:

· Indivíduos: caracterizando uma pessoa na empresa. Por exemplo: João, Maria, etc...

Indivíduos são identificados pelos seus nomes.

· Unidade organizacional: pode representar toda a estrutura organizacional da empresa, como um grupo, ou departamento, divisão, seção, projeto, equipe, etc... Exemplo: Departamento de Planejamento, Assistência técnica.

· Recurso não humano: podem ser máquinas ou sistemas de diferentes tipos. Por exemplo: Aparelho de FAX, “MS Word”.

· Funções: podem ser utilizados pelos Indivíduos e Unidades organizacionais em diferentes contextos. Por exemplo: Autor, Controlador, Supervisor, Gerente, Chefe de Equipe.

Modelo de requisitos e componentes técnicos

Esse modelo define a estrutura e propriedades do sistema de informação para apoiar as atividades de negócio.

Os modelos de Objetivos, Regras de Negócio, Processo de Negócios e Atores e Recursos é uma descrição inicial para a empresa, porém para desenvolver um sistema de informação que suporte esses processos, existe a necessidade de se direcionar a atenção para o sistema técnico que é necessário para apoiar os objetivos, processos e atores da organização.

O relacionamento entre os modelos da metodologia EKD se inter-relacionam de diferentes formas, dependendo do tipo e do objetivo do modelo, conforme a figura abaixo:

Figura: Modelos da metodologia EKD

Capitulo 2 - ORDIT

O ORDIT não desenvolve modelos com múltiplas visões, não considera regras de negócio e não apresenta modelos de processos, o que dificulta o trabalho da captura dos requisitos organizacionais. Trata ainda a responsabilidade das pessoas envolvidas no trabalho, as práticas de trabalho são descritas como responsabilidades e relacionamentos em vez de atividades ou processos e não trata objetivos organizacionais.