Fotografia de José Luciano
Modelos de processo de software
por José Luciano - Terça, 3 Setembro 2019, 08:33
 

Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto.

Exemplos de alguns modelos de processo de software;

  • Modelos ciclo de vida
  • Sequencial ou Cascata (do inglês waterfall) - com fases distintas de especificação, projeto e desenvolvimento.
  • Desenvolvimento iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples de Requisitos de Software e iterativamente alcança evoluções subsequentes das versões até o sistema todo estar implementado
  • Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos.
  • V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com outros modelos mais modernos. Principal ponto é que para cada etapa de um lado tem uma verificação do outro, criando um gráfico no formato da letra V com 2 cascatas.
  • Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.
  • Componentizado - reúso através de montagem de componentes já existentes.
  • Formal - implementação a partir de modelo matemático formal.
  • Ágil
  • RAD
  • Quarta geração.

Modelos de maturidade

Os modelos de maturidade são um metamodelo de processo. Eles surgiram para avaliar a qualidade dos processos de software aplicados em uma organização (empresa ou instituição). O mais conhecido é o Capability Maturity Model Integration (CMMi), do Software Engineering Institute - SEI.

O CMMI pode ser organizado através de duas formas: Contínua e estagiada.

Pelo modelo estagiado, mais tradicional e mantendo compatibilidade com o CMM, uma organização pode ter sua maturidade medida em 5 níveis:

  • Nível 1 - Inicial (Ad hoc): Ambiente instável. O sucesso depende da competência de funcionários e não no uso de processos estruturados;
  • Nível 2 - Gerenciado: Capacidade de repetir sucessos anteriores pelo acompanhamento de custos, cronogramas e funcionalidades;
  • Nível 3 - Definido: O processo de desenvolvimento de software é bem definido, documentado e padronizado a nível organizacional;
  • Nível 4 - Gerenciado quantitativamente: Realiza uma gerência quantitativa do processo de software e do produto por meio de métricas adequadas;
  • Nível 5 - Em otimização: Usa a informação quantitativa para melhorar continuamente e gerenciar o processo de desenvolvimento. Até março/2012, no Brasil, há somente 13 empresas neste nível.

O (MPS.BR), ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. O MPS.BR contempla 7 níveis de maturidade, de A a G, sendo a primeira o mais maduro. Até agosto/2012, no Brasil, há somente 2 empresas neste nível.

Metodologias e métodos

O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologiamétodo como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo.

Assim teríamos, por exemplo, a Metodologia Estruturada, na qual existem vários métodos, como Análise EstruturadaProjeto Estruturado (muitas vezes denominados SA/SD, e Análise Essencial).

Dessa forma, tanto a Análise Estruturada quanto a Análise Essencial utilizam a ferramenta Diagrama de Fluxos de Dados para modelar o funcionamento do sistema.

Segue abaixo as principais Metodologias e Métodos correspondentes no desenvolvimento de software:

Modelagem

A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o entendimento e comunicação do produto final que será desenvolvido.

A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo.

Para a modelagem podemos citar 3 métodos:

Ferramentas, tecnologias e práticas

engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência da computação, enfocando seu impacto na produtividade e qualidade de software.

Destacam-se o estudo de linguagem de programaçãobanco de dadosparadigmas de programação, como:

Ferramenta

Outro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essa classificação abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de software, desde a análise de requisitos e modelagem até programação e testes.

Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam, entre outras coisas:

Gerência de projetos

gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo.

A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização.

Planejamento

O planejamento de um projeto de desenvolvimento de software inclui:

  • Análise Econômica de Sistemas de Informações
  • organização do projeto (incluindo equipes e responsabilidades)
  • estruturação das tarefas (do inglês WBS - work breakdown structure)
  • cronograma do projeto (do inglês project schedule)
  • análise e gestão de risco
  • estimativa de custos

Essas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente a produtividade.

A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas técnicos. Esses fatores requerem uma análise de riscos cuidadosa.

Além da própria identificação dos riscos, há que ter em conta a sua gestão. Seja evitando, seja resolvendo, os riscos necessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.

Análise de requisitos

As atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema de software. De acordo com a ISO/IEC/IEEE 24765 requisito é:

(1) condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo;

(2) condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto;

(3) representação documentada de uma condição ou capacidade como em (1) ou (2);

(4) condição ou capacidade que deve ser alcançada ou possuída por um sistema, produto, serviço, resultado ou componente para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto. Requisitos incluem as necessidades quantificadas e documentadas, desejos e expectativas do patrocinador, clientes e outras partes

interessadas.

Há várias classificações sobre requisitos, o PMBOK e o BABOK utilizam a seguinte classificação hierárquica:

  • Requisitos de negócio
  • Requisitos das partes interessadas
  • Requisitos da solução
  • Requisitos da transição
  • Tanto requisitos da solução como da transição se subdividem em: Requisitos funcionais e não funcionais

É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de sistemas de software, principalmente sobre o custo de cada requisito.

  • Estudo de Viabilidade (Levantamento de Requisitos)

A Engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos de sistema (SOMMERVILLE). Segundo RUMBAUGH, alguns analistas consideram a Engenharia de requisitos como um processo de aplicação de uma metodologia estruturada combinada com a metodologia orientada a objetos. No entanto, a Engenharia de requisitos possui muito mais aspectos do que os que estão abordados por esses métodos.

Abaixo um pequeno Processo de Engenharia de Requisitos (SOMMERVILLE):

Estudo da viabilidade → "Relatório de Viabilidade"

Obtenção e Análise de Requisitos → "Modelos de Sistema"

Especificação de Requisitos → "Requisitos de Usuário e de Sistema"

Validação de Requisitos → "Documento de Requisitos"

O primeiro processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os resultados deste processo devem ser um relatório com as recomendações da viabilidade técnica ou não da continuidade no desenvolvimento do Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido, deverá abordar fundamentalmente as seguintes questões:

  • O Sistema proposto contribui para os objetivos gerais da organização?
  • O Sistema poderá ser implementado com as tecnologias dominadas pela equipe dentro das restrições de custo e de prazo? Ou precisa de treinamentos adicionais?
  • O Sistema pode ser integrado, e é compatível com os outros sistemas já em operação?

Gestão

Existem cinco tipos de gestão: pessoal, produto, processo, projeto e material.

 

 
Ignorar NavegaçãoIgnorar Configurações

Configurações

  • Administração do fórum

Ignorar Calendário

Calendário

Dom Seg Ter Qua Qui Sex Sab
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 Hoje Segunda, 16 Dezembro 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31     
Ignorar Disciplinas