Processo de desenvolvimento de software: diferenças entre revisões
Conteúdo apagado Conteúdo adicionado
Resgatando 1 fontes e marcando 0 como inativas. #IABot (v2.0beta14) |
Adequação ao guia de estilo, {{AP}}, remoção de desambiguação. |
||
Linha 1:
{{mais fontes|data=julho de 2013}}
Um ''processo de desenvolvimento de software'' é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de [[Engenharia de Software]], sendo considerado um dos principais mecanismos para se obter [[Qualidade de software|software de qualidade]] e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a [[
Um outro conceito que podemos utilizar para compreender o processo de desenvolvimento de software foi o apresentado por Waslwick(2013, p 30): é formado por um conjunto de passos de processo parcialmente ordenados, relacionados a artefatos, pessoas, estruturas organizacionais e restrições, tendo como objetivo produzir e manter os produtos de software finais requeridos. Este é um conceito que considera o contexto ao qual o processo de desenvolvimento de software é aplicado destacando as suas interdependências com outros fatores como restrições, pessoas, recursos, padrões etc que impactam no resultado final do processo.
Linha 17:
* [[Rapid Application Development|Desenvolvimento Rápido de Aplicação]] - ''Rapid Application Development (RAD)'', desde 1991
* [[Dynamic Systems Development Method|Metodologia de Desenvolvimento de Sistemas Dinâmicos]] - ''Dynamic Systems Development Method (DSDM)''
* [[Scrum (desenvolvimento de software)|Scrum]], desde 1995
* [[Team Software Process|Team Software Process (TSP)]], desde 1998
* [[IBM Rational Unified Process|Processo Unificado Rational]] - ''Rational Unified Process (RUP)''
Linha 38:
== Passos/Atividades Processo ==
===
{{AP|Análise Econômica de Sistemas de Informações}}
Visa a estabelecer se o projeto de [[Software]] gerará [[lucro]], e se a [[receita (economia)|receita]] gerada será o suficiente para cobrir os [[custo]]s.
===
{{AP|Análise de requisitos de software}}
A extração dos requisitos de um cliente
===
{{AP|Especificação de Programa}}
A especificação é a tarefa de descrever precisamente o software, preferencialmente de uma forma matematicamente rigorosa. Na prática, somente especificações mais bem sucedidas foram escritas para aplicações bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas de software de missão crítica sejam frequentemente bem especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer estáveis.
===
{{AP|Arquitetura de software}}
A arquitetura de um sistema de software remete a uma representação abstrata daquele sistema. Arquitetura é concernente à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura também direciona as [[interface]]s entre os [[sistema de software|sistemas de software]] e outros produtos de software, como também com o [[hardware]] básico ou com o [[sistema operacional]].
===
{{AP|Programação de computadores}}
A transformação de um projeto para um código deve ser a parte mais evidente do trabalho da engenharia de software, mas não necessariamente a sua maior porção.
===
{{AP|Teste de Software}}
Teste de partes do [[software]], especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhando juntos, é um papel da engenharia de software.
Diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto. Onde o principal resultado é o relatório de testes, que contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento em vários aspectos.
===
{{AP|Documentação de software}}
Uma importante tarefa é a documentação do projeto interno do software para propósitos de futuras manutenções e aprimoramentos. As documentações mais importantes são das interfaces externas.
=== Suporte e
Uma grande percentagem dos [[Gerência de projetos|projetos de software]] falham pelo fato de o desenvolvedor não perceber que não importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da fase de desenvolvimento, é muito importante o [[treinamento]] para os [[usuário]]s de software mais entusiasmados, alternando o treinamento entre usuários neutros e usuários favoráveis ao [[software]]. Usuários irão ter muitas questões e problemas de software os quais conduzirão para a próxima fase.
===
{{AP|Manutenção de software}}
A manutenção e melhoria de software lidam com a descoberta de novos problemas e requisitos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar códigos que combinem com o projeto original, mas determinar como o software trabalhará em algum ponto depois da manutenção estar completa, pode requerer um significativo esforço por parte de um engenheiro de software. Cerca de
== Processo de meta-modelos ==
Linha 79 ⟶ 87:
== Métodos Formais ==
{{AP|Métodos formais}}
[[Métodos formais]] em [[ciências da computação]] e [[engenharia de software]], são técnicas baseadas em formalismos [[matemática|matemáticos]] para a [[especificação formal|especificação]], [[desenvolvimento de software|desenvolvimento]] e [[verificação formal|verificação]] dos sistemas de [[software]]s e [[hardware]]s.<ref name="butler">{{citar web|ultimo=Butler|primeiro=Ricky W.|titulo=What is Formal Methods?|url=http://shemesh.larc.nasa.gov/fm/fm-what.html|idioma=inglês|acessadoem=26 março de 2015}}</ref> Seu uso para o desenvolvimento de software e hardware é motivado pela expectativa de que, como em outras disciplinas de engenharia, possam contribuir para a [[Fiabilidade (estatística)|confiabilidade]] e robustez de um projeto executando análises matemáticas apropriadas.<ref>{{Citar periódico|ultimo=Holloway|primeiro=C. Michael|titulo=Why Engineers Should Consider Formal Methods|url=http://klabs.org/richcontent/verification/holloway/nasa-97-16dasc-cmh.pdf|idioma=inglês|local=16th Digital Avionics Systems Conference (27-30 outubro de 1997)|jornal=|acessodata=2015-03-26|arquivourl=https://web.archive.org/web/20061116210448/http://klabs.org/richcontent/verification/holloway/nasa-97-16dasc-cmh.pdf|arquivodata=2006-11-16|urlmorta=yes}}</ref> Entretanto, o alto custo do uso dos métodos formais faz com que, de modo geral, sejam usados apenas no desenvolvimento de sistemas de alta-integridade, nos quais há alta probabilidade de as falhas provocarem perda de vidas ou sério prejuízo.
== Ver também ==
| |||