Ciclo de vida de um software

(postado originalmente em 06/03/2009)

O ciclo de vida de um software, segundo a NBR ISO/IEC 12207 compreende um conjunto de processos, que por sua vez, são compostos por atividades determinadas por um conjunto de tarefas pertinentes.

Como o software pode ser classificado como um produto, o seu desenvolvimento deve envolver um conjunto de processos bem definidos para que este produto seja elaborado com a qualidade adequada para seu fim. Entenda-se por qualidade o equilíbrio entre a eficiência do produto em si, seu custo de produção e o atendimento das necessidades de negócio do problema computacional que se deseja resolver bem como o atendimento dos seus usuários.

O ciclo de vida inicia-se no ‘entendimento’ efetivo do fim ao qual se destina, prolonga-se na fase efetiva de sua construção que é realizada por meio de processos de análise, especificação, codificação, testes, implantação e estabilização.

Normalmente o ciclo de vida é uma coletânea de processos que viabilizam a produção de um software num determinado contexto de necessidades de negócios em um determinado tempo a partir de parâmetros de custo e qualidade previamente definidos (no ato da contratação do serviço de desenvolvimento).

A escolha do conjunto de processos componentes do ciclo de vida é feita por um engenheiro de software, gerente de projetos e/ou de produtos num molde que seja adequado aos parâmetros de custo e prazo (normalmente balizados pela necessidade/urgência do cliente). Os moldes de processos mais comuns no mercado atual são os determinados pelo CMMI (Capability Maturity Model Integration), Scrum e MSF/MSF for Agile Development.

O início de um projeto de software é, normalmente, feito com base em um estudo preliminar dos requisitos de negócio que norteiam o molde/conjunto de processos a serem seguidos/implementados para o desenvolvimento do “produto”. Com base na implantação do processo, as especificações são detalhadas (CMMI) ou reunidas em uma lista de Backlog (Scrum/MSF for Agile) e, enfim desenhadas/planejadas em termos de arquitetura do sistema. A arquitetura definida gera, então, a especificação (formal – CMMI /informal SCRUM) que determina como esse sistema será codificado ou implementado a partir das tecnologias e processos definidos no estudo preliminar dos requisitos de negócio. Ao final (do desenvolvimento do produto – CMMI | de cada SPRINT – SCRUM) o software (ou parte funcional dele) é testado e entregue ao cliente.

Conforme o acordo firmado na contratação, o suporte ao produto é iniciado tendo influência direta sobre as correções de “não-conformidades” ou erros (Bugs) ou ainda na implementação de melhorias coletadas a partir dos retornos dados pelos usuários do software.

(por Mauro Zamaro para a disciplina de Analise e Projeto de Sistemas – CEUCLAR – Rio Claro)

Referências

Microsoft – MSDN. (2009). Modelos e Ferramentas do processo. Retrieved 03 05, 2009, from MSDN: http://msdn.microsoft.com/pt-br/vsts2008/aa718795.aspx

Vários. (n.d.). CMMI . Retrieved 03 05, 2009, from WikiPedia: http://pt.wikipedia.org/wiki/CMMI

Vários. (n.d.). Scrum. Retrieved 03 05, 2009, from WikiPedia: http://pt.wikipedia.org/wiki/Scrum

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s