Quais são as atividades do processo de desenvolvimento de software?

Você já viu o que é processo de software nesse artigo e sabe que ele é composto por 4 atividades principais: especificação, desenvolvimento, validação e evolução. Agora, você irá aprender sobre cada uma delas, destacando seus aspectos mais importantes. Está pronto(a)?

Especificação

Na especificação de software (ou engenharia de requisitos), se definequais os serviços que são necessários no sistema e identificaas restrições na sua operação e desenvolvimento.

É um estágio muito importante e minucioso do processo de software, pois os erros cometidos aqui sempre levam a problemas posteriores na implementação do sistema.

O objetivo da engenharia de requisitos é produzir um documento que especifica o sistema a ser desenvolvido satisfazendo os requisitos das partes interessadas. Eles são geralmente apresentados em dois níveis de detalhes: alto nível para usuários finais e clientes; e baixo nível (mais detalhado) para os desenvolvedores.

Existem quatro atividades principais na engenharia de requisitos (Figura 1):

1. Estudo de viabilidade. É feito um levantamento de quais necessidades do usuário podem ser atendidas utilizando as tecnologias atuais (de software ou hardware). Esse estudo deve ser relativamente barato e rápido e considera se o sistema proposto será rentável do ponto de vista empresarial e se pode ser desenvolvido dentro das restrições orçamentárias existentes. Ao final, o resultado deve informar a decisão de prosseguir ou não com uma análise mais detalhada.
2. Elicitação e análise de requisitos. Informações sobre o sistema são obtidas através de, entre outros modos, observação dos sistemas existentes, discussões com potenciais usuários e compradores, e análise de tarefas. Podem ser feitos modelos e protótipos para ajudar a entender o sistema que será especificado.
3. Especificação de requisitos. As informações coletadas durante o processo de análise são traduzidas em um documento que define um conjunto de requisitos. Eles podem ser: requisitos do usuário, que são declarações abstratas; e requisitos do sistema, que descreve detalhadamente a funcionalidade a ser fornecida.
4. Validação de requisitos. Os requisitos são analisados quanto ao seu realismo, consistência e integridade. Durante a análise,, erros no documento de requisitos são descobertos e corrigidos.

Na prática, essas atividades não seguem uma ordem. A análise de requisitos continua durante a especificação e novos requisitos aparecem em qualquer momento do processo. Portanto, as atividades de análise, especificação e validação são intercaladas. Em métodos ágeis, os requisitos são desenvolvidos de forma incremental de acordo com as prioridades do cliente e a elicitação de requisitos vem dos usuários que fazem parte da equipe de desenvolvimento.

Design e implementação

Nesse estágio, a especificação é convertida em um sistema executável, através de processos de design e programação do software.

O design de software é a descrição da arquitetura do sistema a ser implementado, dos modelos e estruturas de dados que serão usados, das interfaces entre os componentes e, às vezes, dos algoritmos utilizados. Os designers e projetistas de software desenvolvem o projeto iterativamente, adicionando formalidade e detalhes à medida que constroem o design, com retrocesso constante para corrigir versões anteriores.

A Figura 2 é um modelo abstrato da fase de design, mostrando as entradas para o processo de design, as atividades intermediárias e os documentos produzidos como saídas.

O diagrama sugere que os estágios do processo de design sejam sequenciais. Na verdade, eles são intercalados, já que existe o feedback de um estágio para outro e o consequente retrabalho do design.

As entradas do processo de design são:

• Informações da plataforma na qual o software irá operar — isso inclui o sistema operacional, banco de dados, middleware e outras aplicações. Com as informações da plataforma, os designers devem decidir como melhor integrá-la ao ambiente do software.
• Especificação de requisitos, que, como você já viu, é uma descrição das funcionalidades que o software deve fornecer.
• Descrição de dados com os quais o sistema irá operar. Essa entrada é opcional, porque, se o sistema for trabalhar com processamento de dados existentes, a descrição desses dados pode ser incluída na especificação da plataforma; mas se sistema for trabalhar com novos dados, a descrição deles deve ser uma entrada, para que seja definida a organização que fornecerá os dados.

As atividades do processo de design variam dependendo do tipo de sistema que está sendo desenvolvido. Por exemplo, sistemas em tempo real exigem design de temporização, mas podem não precisar de um banco de dados e, portanto, não há design de banco de dados. O diagrama da Figura 2 mostra quatro atividades que podem fazer parte do processo de design para sistemas de informação:

1. Design da arquitetura. São identificados a estrutura geral do sistema, os módulos e componentes principais, seus relacionamentos e como eles são distribuídos;
2. Design da interface. São definidas as interfaces entre os componentes do sistema. A especificação das interfaces deve ser clara, pois, com uma interface precisa, um componente pode ser usado sem que outros saibam como ele é implementado. Quando as especificações da interface são concordadas, os componentes podem ser projetados e desenvolvidos simultaneamente.
3. Design dos componentes. É planejado como cada componente do sistema irá operar. À vezes, é escrita uma descrição da funcionalidade que se espera do componente, com um design específico destinado ao programador; ou pode ser uma lista de alterações a serem feitas em um componente reutilizável.
4. Design do banco de dados. São projetadas as estruturas de dados do sistema e como elas devem ser representadas em um banco de dados. Novamente, o trabalho aqui depende da origem dos dados. Se já existe um banco de dados, ele deve ser reutilizado. Se não, deve ser criado um novo banco de dados.

Essas atividades levam a um conjunto de saídas, que também são mostradas na Figura 2. O detalhamento e representação dessas saídas variam para cada tipo de software. Para sistemas críticos (ditos os softwares que exigem alta segurança e confiabilidade, como os para bancos e companhias aéreas), as especificações devem ser bem detalhadas e claras. Se a abordagem estiver associada a algum modelo, essas saídas podem ser diagramas. Quando são usados métodos ágeis de desenvolvimento, as saídas do processo de design podem ser representadas no próprio código do programa.

Validação

Validação de software — ou, comumente, verificação e validação (V & V) — tem a intenção de mostrar que um sistema está em conformidade com sua especificação e atende às expectativas do cliente. A validação também pode envolver a inspeção de cada estágio do processo de software (desde a definição dos requisitos até o desenvolvimento do programa), com a finalidade de checar se o programa foi construído da forma correta.

Uma maneira de validar um software é realizar testes. Os testes mais comuns são:

1. Teste de componentes. Os componentes que compõem o sistema são testados pelos programadores. Cada componenteé avaliado de forma independente. Esses componentes podem ser entidades simples, como funções ou classes de objetos, ou podem ser agrupamentos coerentes dessas entidades. Ferramentas de automação de teste são muito usadas, como o JUnit, já que executam testes sempre que novas versões do componente são criadas.
2. Teste de sistema. Os componentes são integrados para criar um sistema completo. Esse teste é indicado para localizar erros que resultam das interações imprevistas entre componentes e problemas nas interfaces. Também pode mostrar que o sistema atende aos requisitos funcionais e não funcionais. Para sistemas complexos, o processo de teste pode ser mais extenso: os componentes são integrados para formar subsistemas intermediários que são testados individualmente antes que sejam integrados para formar o sistema final. O teste de sistema é a principal técnica de validação.
3. Teste de aceitação. Este é o estágio final do processo de teste antes que o sistema seja aceito para uso operacional. O sistema é testado com dados fornecidos pelo cliente (diferente das etapas anteriores que usam dados simulados). O teste de aceitação pode revelar erros e omissões na definição de requisitos, problemas na instalação do sistema ou no desempenho.

Idealmente, os defeitos dos componentes são descobertos no início do processo e os problemas de interface são encontrados quando o sistema é integrado. No entanto, erros nos componentes do programa podem surgir durante o teste do sistema, por exemplo. Quando um defeito é descoberto, o programa deve ser depurado e isso pode exigir que outras etapas do processo de teste sejam repetidas. O processo de teste é, portanto, iterativo, com informações sendo retornadas para etapas anteriores frequentemente.

Normalmente, as partes de teste de componentes e de sistema são intercalados. Os programadores criam seus próprios dados de teste e testam incrementalmente o código à medida que ele é desenvolvido. Na abordagem Extreme programming (XP), os testes são desenvolvidos em conjunto com os requisitos antes do início do desenvolvimento. Isso ajuda os testadores e desenvolvedores a entender os requisitos e garante que não haja atrasos à medida que os casos de teste são criados. Para sistemas críticos, o teste é realizado por uma equipe de testadores e conduzido por um conjunto de planos de testes desenvolvidos a partir da especificação e do design do sistema.

O teste de aceitação é, às vezes, subdividido nos chamados “teste alfa” e “teste beta”. Os testes alfa são realizados pelo próprio time de desenvolvimento ou por outros funcionários internos que simulam usuários reais. Já nos testes beta, uma versão do sistema é entregue à potenciais usuários que utilizam o sistema em seu ambiente real e relatam problemas aos desenvolvedores.

Evolução

Esta é a última e a mais longa etapa do ciclo de vida do software. Aqui, o programa passa por mudanças para corrigir defeitos e deficiências que foram encontrados durante o uso operacional e adicionar novas funcionalidades a fim de melhorar a aplicabilidade e usabilidade do software.

Todos os erros, relatados pelos usuários durante sua utilização ou por meios dos testes executados pela própria equipe após a entrega do produto, são localizados e corrigidos para gerar novas versões do software, que são as conhecidas atualizações.

Existem três tipos de evolução/manutenção de software:

• Adaptativas. São todas as alterações que buscam adequar o software a um novo ambiente ou realidade. Por exemplo, quando o governo altera ou legitimiza uma lei que está diretamente relacionada ao ambiente no qual o software atua, ele precisa passar por mudanças para adaptá-lo a ela.
• Corretivas. Servem para corrigir quaisquer defeitos encontrados no software.
• Evolutivas. São alterações que adicionam novas funcionalidades e melhorias.

Quando se trata de migrar o software para uma nova tecnologia, seja de hardware ou de software, há uma diferença quanto à classificação dessa manutenção. Se a tecnologia for imposta (por estar obsoleta, por exemplo), a manutenção é classificada como adaptativa. Se a tecnologia for uma solução para melhorar o sistema, é classificada como evolutiva.

Quais as atividades do processo de desenvolvimento de software?

Quais os processos de desenvolvimento de software?

Quais são as principais atividades de engenharia de software?