Introdução à Análise e Modelagem de Sistemas

Fundamentos da análise e modelagem de sistemas

Olá, estudante! Nesta videoaula, você conhecerá a jornada da Evolução de Software, mergulhando nos fundamentos do papel crucial desempenhado pelo analista de sistemas. Abordaremos também as nuances do projeto de software, destacando sua importância na criação de soluções eficientes. Este conhecimento é essencial para todos os profissionais da área, capacitando-os a compreender e adaptar-se às constantes transformações no cenário tecnológico. Prepare-se para aprimorar suas habilidades e impulsionar sua prática profissional.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Trabalhar na área de análise de sistemas é sempre desafiador, pois um sistema nunca é igual ao outro e há constantes novidades advindas do emprego de tecnologias diferentes. Nesse universo, são necessários organização e muito empenho para produzir um software de qualidade.

Os sistemas são conjuntos de componentes inter-relacionados, trabalhando juntos para coletar, processar, armazenar e disseminar informações. Eles são fundamentais para entender como as informações são gerenciadas e utilizadas nas organizações. As características essenciais dos sistemas incluem a interconexão de partes, a existência de um objetivo ou propósito, a capacidade de processamento de dados e informações, e a interação com o ambiente. Compreender esses conceitos básicos é crucial para a análise, o design e a implementação eficazes de sistemas de informação, pois oferecem a base para a identificação de problemas e a busca de soluções tecnológicas apropriadas.

A análise de sistemas envolve a investigação detalhada de sistemas existentes ou propostos para determinar as necessidades e objetivos do usuário e desenvolver soluções estratégicas. Esses princípios incluem entender as necessidades dos usuários, identificar e resolver problemas, desenhar soluções eficazes e eficientes, e garantir a adaptabilidade e escalabilidade do sistema. O conhecimento desses princípios é vital para desenvolver sistemas que não apenas atendam aos requisitos atuais, mas também sejam flexíveis o suficiente para se adaptar às necessidades futuras.

O analista de sistemas é um profissional crucial na ponte entre a tecnologia e as necessidades de negócios de uma organização. Eles são responsáveis por compreender os requisitos do negócio e traduzi-los em especificações técnicas para o desenvolvimento de sistemas de informação. Isso inclui a realização de análises de requisitos, a proposição de soluções, o acompanhamento do desenvolvimento do software e a garantia de que o produto final atenda às expectativas do cliente. O papel de um analista de sistemas é fundamental para garantir que os recursos de TI sejam usados de maneira eficiente e eficaz, contribuindo para o sucesso operacional e estratégico da organização.

Pensando nesses conceitos, suponha que você foi convidado a trabalhar como analista de sistemas em um software house (empresa de desenvolvimento de sistemas) e sua primeira missão é analisar um software de um possível cliente. A empresa de desenvolvimento precisa de novas ideias para sugerir ao cliente e, quem sabe, conseguir fechar um contrato de desenvolvimento.

O cliente possui uma rede de postos de coleta de exames laboratoriais no Sul do país. Sabe-se que o sistema utilizado atualmente, um desktop sem acesso à internet, já possui quase 15 anos de uso e nunca foi atualizado. Como a empresa pensa, agora, em atualizá-lo, sua missão será descobrir:

• É mais viável atualizar o sistema existente ou criar um novo?
• Quais as novas tecnologias que podem ser utilizadas em um novo sistema para uma empresa de exames laboratoriais?
• Quais processos deverão ser adotados para manter o software sempre atualizado?
• Qual o perfil dos profissionais envolvidos no processo da análise do sistema do cliente?

Crie um relatório com as soluções encontradas para gerar um debate sobre suas ideias.

Vamos Começar!

Conceitos básicos de sistemas e suas características

Na era moderna, o uso de softwares se tornou extremamente difundido em vários aspectos da vida. Hoje em dia, é normal que as empresas exijam que seus empregados tenham competência em softwares específicos, ou providenciem treinamento para seu uso, visto que softwares são frequentemente empregados em atividades cotidianas.

Sommerville (2018) define softwares como "programas de computador acompanhados de documentação associada", e esclarece que eles podem ser criados para clientes específicos ou para um público mais amplo. Por outro lado, Pressman (2021) descreve softwares de computador como produtos desenvolvidos e mantidos a longo prazo por profissionais de Tecnologia da Informação (TI). Ele também destaca que softwares englobam qualquer forma de mídia eletrônica e são constituídos por três elementos principais:

• Instruções: quando executadas, fornecem os atributos e funções de desempenhos desejados pelos usuários.
• Estruturas de dados: possibilitam aos programadores manipular as informações de forma mais adequada conforme a necessidade da aplicação.
• Documentação: é toda a informação descritiva do software, a qual detalha a operação de uso dos programas, diagramas de funcionalidades, etc.

Deve-se destacar que o desenvolvimento do software não ocorreu instantaneamente; ele foi fruto de uma evolução contínua, cujo conhecimento é fundamental para todos os profissionais de Tecnologia da Informação. No Quadro 1, é apresentada uma linha do tempo que ilustra a história e a evolução do software, incluindo os eventos mais significativos que marcaram essa trajetória.

Quando?	O que?	Descrição
Década de 1940	Programa	O programa era executável e tinha controle total sobre o computador, sendo que o software era responsável por todo o funcionamento tanto do hardware (Sistema Operacional) quanto das operações matemáticas que teria que fazer.
Décadas de 1950 e 1960	Sistemas operacionais	Responsáveis pelo controle do hardware (realizavam a interface entre o homem e a máquina).
	Linguagens de programação	Surgem as linguagens de programação: COBOL, LISP, ALGOL, BASIC etc.
Décadas de 1960 e 1970	Crise do software	Houve um grande crescimento do número de sistemas e quase não havia planejamento e controle de processos de desenvolvimento de software. Devido ao desenvolvimento informal, havia atrasos e os custos superavam o orçamento estimado (surgindo a necessidade de criar métodos de engenharia de software).
	Paradigmas de programação	Com novas linguagens sendo criadas, nessa época o conceito de orientação a objetos é criado.
	Sistemas operacionais mais eficientes	O foco, no momento, era a programação desktop, de modo que foi quando surgiram o MS-DOS da Microsoft e o Macintosh da Apple.
Década de 1980	Computador desktop	A década foi marcada pelo surgimento da Microsoft e pela evolução dos computadores pessoais - desktop.
	Unix	O Unix (sistemas operacionais em rede) avançou pelo mundo.
	Evolução da internet	A internet começa a despontar como meio comunicação.
Década de 1990	Internet	A internet é amplamente utilizada.
	Linux	Surge o núcleo do futuro Linux.
	JAVA	Nasce a linguagem JAVA, que revoluciona o paradigma da orientação a objetos.
Década de 2000	Sistemas operacionais gráficos	Geração do Windows da Microsoft (Windows XP, Windows Vista, Windows 70) e versões gráficas do LINUX.
	Internet	Softwares que utilizam a web como plataforma de funcionamento.
Década de 2010 e 2020	Computação em nuvem	Utilizada em larga escala por diversos seguimentos de empresas.
	Aplicativos para dispositivos móveis	Com a evolução dos dispositivos móveis os softwares para aplicativos tornaram-se essenciais.
	Inteligência Artificial	Utilização de algoritmos para a Deep Learning (aprendizagem profunda) e Machine Learning (aprendizado de máquina).

Quadro 1 | Cronologia histórica da evolução do software. Fonte: adaptado de Fonseca Filho (2007).

Conforme apresentado no Quadro 1, é notável que, com a evolução e maior acessibilidade do hardware e software, cresce a urgência de aprimorar os softwares. Paralelamente, as exigências dos consumidores evoluem com a disponibilidade de novas tecnologias. Vejamos alguns exemplos:

1. Nos anos 90, uma empresa geralmente precisava de um software e, possivelmente, de um site na internet para ganhar visibilidade. O site funcionava principalmente como um cartão de visitas virtual.
2. Na década de 2000, essa necessidade evoluiu para um software com capacidade de conexão à internet, permitindo oferecer mais recursos aos clientes.
3. Já em 2010, tornou-se essencial que a empresa dispusesse de um software, um site e um aplicativo móvel, facilitando o acesso a seus serviços em diferentes dispositivos e o armazenamento de dados na nuvem.
4. A partir de 2020, muitas empresas começaram a explorar o uso da Inteligência Artificial para otimizar seus processos de gestão.

Esses desenvolvimentos demonstram claramente que, à medida que novas tecnologias ganham popularidade, aumenta a demanda por software sofisticado para atender às necessidades em constante mudança da sociedade.

Alterações são uma constante no ciclo de vida de um software, ocorrendo durante seu desenvolvimento, na fase de entrega, e mesmo após ser entregue. Ajustes e correções frequentemente se fazem necessários, e muitas vezes surgem pedidos para adicionar novas funcionalidades, geralmente a pedido do cliente. O software, portanto, passa por várias manutenções devido a essas novas solicitações. Após múltiplas modificações, que podem introduzir novos desafios, pode surgir a necessidade de desenvolver um novo software.

Ao longo da vida útil de um software, ele passará por diversas mudanças, que podem introduzir novos erros e aumentar a taxa de defeitos. Esse fenômeno é ilustrado na Figura 1.

A Figura 1 exibe a curva de defeitos em softwares (taxa de defeitos) ao decorrer do tempo. Esse gráfico inclui uma curva teórica mostrando que a taxa de defeitos é inicialmente alta no começo do desenvolvimento do software, mas diminui progressivamente até se estabilizar. Contudo, na realidade, esse padrão ideal raramente se verifica, pois frequentemente são exigidos acréscimos de novas funcionalidades (solicitadas pelo cliente) ou alterações para corrigir problemas detectados. Portanto, a curva real é introduzida, evidenciando que, conforme mudanças são implementadas no software, ele pode se tornar mais suscetível a falhas. Essas alterações podem resultar em novos erros ou defeitos, como indicado pelos picos no gráfico, que simbolizam o aumento nas taxas de defeitos. Muitas vezes, essas melhorias precisam ser feitas de forma rápida, levando a uma negligência no processo de documentação para acelerar as mudanças. Este ciclo de modificações pode resultar em um software mais propenso a falhas e ao surgimento de mais erros.

Diferentemente do hardware, que se desgasta fisicamente devido a fatores ambientais como altas temperaturas, poeira e vibrações, o software não sofre deterioração física. No entanto, os softwares podem se deteriorar devido às mudanças que são implementadas neles. É importante notar que a taxa de defeitos no hardware pode ser influenciada não apenas por fatores ambientais, mas também por picos de processamento exigidos pelo software. Isso ocorre quando os recursos de hardware (memória, processador, placa de vídeo) não são suficientes para suportar a execução de um software específico. Um exemplo disso são jogos que demandam placas de vídeo de alta capacidade computacional; eles podem apresentar falhas devido ao superaquecimento do processador e da placa de vídeo.

Siga em Frente...

Princípios da análise de sistemas

Os fundamentos da análise de sistemas residem na importância de conduzir estudos detalhados dos processos, a fim de identificar a solução mais adequada para o desenvolvimento de um sistema. De acordo com Roth, Dennis e Wixom (2014), a análise de sistemas é ancorada em métodos e técnicas de pesquisa e especificação, visando descobrir a solução mais eficaz para um problema ou necessidade computacional específica de uma área de negócios, baseando-se nas funcionalidades identificadas pelo analista de sistemas.

Em uma visão mais generalizada das fases que envolvem os processos da análise de sistema, destacam-se, conforme Pressman (2021):

• Análise: esta etapa envolve a realização de estudos focados na especificação do software. O objetivo é avaliar sua viabilidade, considerando o custo-benefício, estabelecer as funcionalidades necessárias do software, e definir o escopo, incluindo a alocação de recursos e a elaboração do orçamento. Os resultados obtidos nesta fase serão fundamentais para as etapas subsequentes.
• Projeto: nesta fase, o foco é na definição lógica do software. Envolve a elaboração dos layouts de telas e relatórios, a construção da estrutura de banco de dados e a criação de diagramas gráficos para o desenvolvimento do software.
• Implementação: esta etapa consiste na codificação do software, utilizando a linguagem de programação selecionada na fase de análise.
• Testes: com o objetivo de identificar erros, são conduzidos testes para verificar as funcionalidades dos componentes codificados.
• Documentação: esta fase envolve a elaboração de documentação para todos os processos e diagramas desenvolvidos em todas as etapas. Utiliza-se documentação padronizada (e adaptada por cada empresa de desenvolvimento) como meio de comunicação entre os envolvidos no desenvolvimento e como parte do contrato entre as partes interessadas na produção do software.
• Manutenção: após a implantação e início de operação do software, esta fase se dedica ao monitoramento, registro e correção de falhas, além de propor melhorias ou adicionar novas funcionalidades.

As fases descritas devem incluir um processo de homologação, que é a aprovação oficial do cliente, para validar os documentos produzidos. É essencial que o cliente compreenda que, uma vez aprovada uma etapa, quaisquer alterações posteriores afetarão os custos e poderão resultar em ajustes no cronograma, incluindo possíveis atrasos.

Sommerville (2018) e Pressmann (2021) destacam alguns princípios da análise de sistemas, são eles:

• É fundamental que a compreensão da informação relativa a um problema específico seja clara e compartilhada por todos os envolvidos no projeto.
• As funcionalidades do software devem ser inicialmente definidas e descritas de maneira ampla, refinando-se progressivamente até alcançar um nível mais detalhado.
• O comportamento do software deve ser ilustrado por meio de suas interações com o ambiente externo, incluindo usuários e outros sistemas.
• Os diagramas que ilustram as funções e comportamentos do software devem ser estruturados em camadas, decompondo um problema complexo em partes menores para facilitar a compreensão
• A análise deve começar com informações essenciais e avançar até os detalhes de implementação, sem se preocupar inicialmente com a codificação específica da solução; os detalhes de implementação definirão como a solução será efetivamente realizada.

O papel do analista de sistema

O analista de sistemas é o profissional encarregado de conduzir atividades de análise de sistemas, incluindo pesquisa, planejamento, coordenação de equipes de desenvolvimento e sugestão de soluções de software adequadas às necessidades de desenvolvimento ou resolução de problemas empresariais. As responsabilidades do analista de sistemas abrangem a concepção, implementação e implantação de software. A tarefa inicial é determinar as funcionalidades que o sistema deve ter, seguida pela compreensão e avaliação das necessidades e expectativas dos usuários do software, para que estas possam ser organizadas, especificadas e documentadas adequadamente (SOMMERVILLE, 2018).

O papel do analista de sistemas envolve desenvolver especificações, funcionalidades e transações, adaptando soluções para atender às demandas dos usuários. Essencialmente, esse profissional deve ter conhecimento sobre diversas áreas de negócio e, na ausência de domínio em algum tema específico, deve ser proativo em buscar informações sobre o campo de aplicação do software.

Uma habilidade importante para o analista de sistemas é possuir uma perspectiva empresarial aguçada, contribuindo assim para os processos gerenciais na criação do software. As competências valiosas para um analista de sistemas incluem: estar atualizado com as tecnologias, ter organização e método, visão gerencial, excelente habilidade de relacionamento interpessoal, entre outras.

O analista de sistemas atua como um intermediário entre os desenvolvedores de software e os usuários finais. Sua responsabilidade é entender as necessidades e desejos dos usuários e determinar o que é tecnicamente factível para desenvolver. O papel do analista inclui coletar informações dos usuários, interpretar esses dados e comunicá-los aos programadores de uma maneira técnica. Isso garante que o software desenvolvido esteja alinhado com as expectativas tanto do cliente quanto dos usuários finais.

Durante o desenvolvimento de um software, o analista de sistemas possui as seguintes atribuições:

• Interagir com clientes e usuários para entender suas necessidades em relação ao software.
• Avaliar custos e determinar a viabilidade do projeto de software.
• Coletar informações essenciais entrevistando os usuários do software.
• Identificar dados e requisitos essenciais para análise e desenvolvimento de soluções.
• Desenvolver a modelagem do software.
• Guiar os desenvolvedores durante todo o processo de criação do software, incluindo aspectos lógicos e de interface gráfica.
• Conduzir e monitorar os testes do software.
• Gerenciar a documentação completa do software.
• Administrar mudanças que ocorram durante o projeto.
• Estabelecer padrões para o desenvolvimento do software.
• Assegurar que a qualidade do software atenda às expectativas do cliente.
• Executar monitoramento e auditorias para identificar possíveis falhas.
• Organizar e ministrar treinamentos para os usuários do software.
• Supervisionar a implantação do software, assegurando a integração e adaptação aos sistemas do cliente.
• Oferecer consultoria técnica para entender as necessidades dos clientes em diferentes áreas de negócio.
• Pesquisar novas tecnologias e fornecedores, e buscar aperfeiçoamento profissional para a equipe de desenvolvimento. 

Vamos Exercitar?

Chegou o momento de resolver o desafio que lhe foi proposto no início da aula!  Você está trabalhando em um software house e, como primeira missão nessa empresa, você precisa avaliar um software de exames laboratoriais a fim de recomendar novas tecnologias para ele, as quais, caso aprovadas, serão utilizadas. O software em questão é de uma empresa com diversas filiais no Sul do país, que há 15 anos utiliza o mesmo software desktop (sem acesso à internet).

Vamos começar essa análise avaliando se é mais viável atualizar o sistema existente ou criar um novo. O atual software que a empresa utiliza é limitado ao ambiente desktop, ou seja, não é um sistema projetado para funcionar com os recursos da internet. Esse é um importante ponto, pois, se a empresa possui filiais, é crucial que ela tenha um sistema central, o qual as filiais acessem via internet, mantendo todo o sistema integrado. Veja que, mesmo sem avaliar as funcionalidades desse sistema legado, já sabemos que não é viável usá-lo. Dessa forma, teremos que propor um novo sistema que suporte transações on-line.

Pois bem, sabendo que precisamos de um novo sistema, quais tecnologias podem ser utilizadas?

Para determinar as novas tecnologias a serem utilizadas em um novo sistema, deverá ser feito um trabalho de investigação para o qual recomenda-se os seguintes passos:

1. Visitar uma unidade da empresa para acompanhar o funcionamento do sistema.
2. Acompanhar o cadastramento da coleta de exames de um paciente a fim de observar o tempo gasto.
3. Verificar como é realizada a entrega dos resultados.
4. Descobrir qual a linguagem de programação utilizada e como é o funcionamento do banco de dados.

Após o trabalho investigativo, algumas tecnologias já podem ser apontadas:

• Criação de um site e de um aplicativo que permitam:
  • Marcar o exame.
  • Agendar a coleta em casa (caso o cliente assim deseje).
  • Acompanhar o andamento da análise laboratorial dos exames solicitados.
  • Visualizar os resultados dos exames.
  • Disponibilizar os resultados para que sejam impressos pelo paciente.
• Armazenamento do banco de dados em nuvem. Nesse caso, você deverá consultar os três grandes players (Amazon, Google e Microsoft) e fazer um levantamento de custos.
• Utilização da linguagem JAVA como sugestão de linguagem de programação para diminuir os custos para o cliente.

E qual deverá ser o perfil dos profissionais envolvidos no processo da análise do sistema do cliente? O ideal é ter, na equipe de desenvolvimento, analistas de sistemas com as seguintes habilidades: conhecimento tecnológico atualizado, organização e método, visão gerencial e ótimo relaciona- mento interpessoal. Um dos papéis do analista de sistemas é a atualização tecnológica constante, fator importante justamente nos casos em que um cliente pede ajuda para atualizar seus sistemas.

E como saber quais os processos que deverão ser adotados para manter o Software sempre atualizado? Imagine o seguinte cenário: após a entrega do software, foi verificado que nele poderiam ser utilizados códigos de barras e QR-Code. Na sua visão, o que precisa ser feito?

Acrescente itens à lista, crie um relatório com as soluções encontradas. 

Saiba Mais

Quer entender mais sobre a profissão de um analista de sistema, leia o artigo:

SERASA EXPERIAN. O que faz um analista de sistemas?. 2022.

Leia mais sobre a natureza e definição do software no livro Engenharia de software, em Capítulo 1, seção 1.1 e 1.2, disponível na Biblioteca Virtual:

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Grupo A, 2021.

Quer compreender mais sobre a evolução de software? Leia o seguinte artigo: AZEVEDO. D. J. P. Evolução de Software. Bate Byte. [s. d.] 

Referências Bibliográficas

FONSECA FILHO, C. História da computação: o caminho do pensamento e da tecnologia. Porto Alegre: EDIPUCRS, 2007.

PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021. 

SOMMERVILLE, Ian. Engenharia de software. 10. ed. São Paulo: Pearson, 2018. 

ROTH, R. M.; DENNIS, A.; WIXOM, B. H. Análise e projeto de sistemas. 5. ed. Rio de Janeiro: LTC, 2014.

Processos de software

Bem-vindo à nossa videoaula! Neste encontro, exploraremos os intricados Processos de Software e a importante Modelagem das Atividades, oferecendo insights valiosos para sua prática profissional. Compreenderemos a importância desses processos na construção de software eficiente e examinaremos como as tarefas moldam cada etapa. Além disso, mergulharemos no universo da Qualidade do Software, destacando sua relevância para assegurar resultados excepcionais. Prepare-se para aprimorar suas habilidades e elevar sua atuação no desenvolvimento de software!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Na aula de hoje, vamos explorar os Processos de Software, um tema essencial para profissionais de tecnologia da informação, como desenvolvedores e analistas. Esses processos são mais do que apenas escrever código; eles envolvem uma série de atividades planejadas e executadas que são cruciais para desenvolver um software eficaz e confiável. Vamos cobrir desde os fundamentos da criação de software até a entrega ao cliente, enfatizando a importância de cada etapa do processo. Essa discussão incluirá as práticas comuns na indústria e como elas se aplicam a diferentes tipos de projetos de software, proporcionando uma visão clara da importância dos Processos de software no desenvolvimento tecnológico.

Em seguida, abordaremos as Tarefas e a Modelagem das atividades do processo de software. Essas tarefas são componentes cruciais no processo de desenvolvimento, e entender como elas se interligam é fundamental. A modelagem de atividades ajuda a visualizar o processo de desenvolvimento, identificar desafios e encontrar soluções eficazes. Um aspecto crucial que exploraremos é a Qualidade do software. A qualidade é um objetivo constante, integrado em cada fase do desenvolvimento, e não apenas uma etapa final. Vamos discutir estratégias para assegurar que o software atenda às necessidades do cliente e seja ao mesmo tempo robusto, seguro e eficiente. Esta aula é para aqueles que querem aprimorar seus conhecimentos e habilidades em engenharia de software, com foco na qualidade como um elemento fundamental dos seus projetos.

Pensando nesses conceitos, imagine que você é um Analista de sistemas em uma software house, você realiza diversas tarefas, atendendo diferentes clientes. Alguns clientes têm relatado um incômodo, quanto ao tempo de entrega do produto final, o software. Para ajudar a empresa, você possui a missão de investigar o Processo de software da empresa e propor melhorias. Para isso, deverá se concentrar em responder os seguintes questionamentos:

• Quais as atividades principais de um Processo de software?
• Como você poderia melhorar o Processo de construção de um software?

Vamos Começar!

Processo de software

De acordo com Sommerville (2018), um processo de software é um conjunto de atividades inter-relacionadas e resultados que conduzem à criação de um software. Pressman (2021) salienta que, na Engenharia de software, um processo não implica um método rígido de desenvolvimento, mas sim oferece uma abordagem flexível que permite à equipe de desenvolvimento selecionar processos alinhados com a filosofia da empresa, visando a qualidade do produto, cumprimento de prazos e redução de custos.

Sommerville (2018) também menciona que a metodologia organizada adotada pela Engenharia de software para a produção de software é conhecida como processo de software. Esse processo geralmente engloba várias atividades, incluindo especificação, design, implementação, validação, manutenção e evolução. Destaca-se os seguintes pontos sobre o processo de software:

• Estabelece um padrão para a criação de serviços e produtos.
• Facilita a repetição e reutilização de serviços e produtos, aproveitando componentes já desenvolvidos e padronizados.
• Preserva o conhecimento dentro da empresa, permitindo que novos membros continuem os processos estabelecidos.
• Define e orienta as atividades de um Projeto de Software.
• Específica todo o processo ou partes do processo de desenvolvimento de software.
• Determina as tarefas a serem realizadas pela equipe e individualmente.
• Minimiza riscos e torna os resultados mais previsíveis.
• Fornece uma base comum de entendimento para a equipe de desenvolvimento, melhorando a comunicação.
• Pode ser usado como um modelo para outros projetos, aumentando a eficiência em novos projetos de software.

Conforme explicado por Engholm Jr. (2010), ao estabelecer processos de software, diversos parâmetros são determinados:

1. O evento que marca o início do processo.
2. A matriz de responsabilidades atribuídas.
3. As atividades a serem realizadas, juntamente com a ordem em que devem ser executadas.
4. As entradas e saídas associadas a cada atividade.
5. As regras e políticas que devem ser seguidas durante a execução das atividades.
6. A infraestrutura necessária para a realização do processo.
7. Os resultados produzidos ao final de cada processo.

Além disso, a Figura 1 ilustra que, dentro de cada Processo de Software, várias atividades podem ocorrer, seja de forma sequencial ou em paralelo.

Como apresentado na Figura 1, um processo de software é caracterizado por várias entradas e saídas. Ele se compõe de uma sequência de atividades padronizadas, que são organizadas em diferentes fases. Nessas fases, ocorrem mudanças nas atividades realizadas. Em cada uma dessas fases, são estabelecidos elementos chave, como as responsabilidades (definindo quem fará o quê), os prazos de entrega, e as estratégias para alcançar os objetivos propostos. A Figura 2 apresenta um diagrama do processo de software, onde se nota que cada atividade metodológica é formada por uma série de ações no campo da engenharia de software. Estas ações são detalhadas por um conjunto de tarefas específicas, as quais determinam as tarefas de trabalho a serem concluídas, os artefatos de software a serem produzidos, os critérios de garantia de qualidade a serem seguidos e os marcos indicativos de progresso.

O processo de software adotado em uma empresa pode ser completamente diferente de outra empresa, cada qual procura encontrar e estabelecer atividades que visam aumentar a qualidade e baixar o custo de produção do software produzido. Independente do modelo de Processos de Software adotado pela empresa de desenvolvimento, todos utilizam uma Estrutura de Processo Genérico de Software, com atividades pré-estabelecidas.

Siga em Frente...

Tarefas e modelagem das atividades do processo de software

As etapas envolvidas em qualquer processo de software são cruciais para a criação de um produto de software finalizado e entregue ao cliente. Dentro de um Processo Genérico de Software, como descrito por Sommerville (2018), embora os processos possam variar entre diferentes projetos, existem quatro atividades fundamentais comuns a todos os projetos de desenvolvimento de software:

• Especificação de software: esta etapa envolve definir o escopo do projeto, incluindo suas funcionalidades e limitações.
• Projeto e implementação de software: esta fase abrange o desenho e a codificação (programação) do software, garantindo que ele atenda às especificações definidas.
• Validação de software: Nesta etapa, é realizada a verificação para assegurar que o software desenvolvido atende às necessidades e requisitos do cliente.
• Evolução de software: esta atividade implica em adaptar e atualizar o software para atender às demandas em mudança e às solicitações de melhorias feitas pelo cliente.

Dentro do Processo genérico de software, cada atividade é uma parte integrante da Engenharia de software. Segundo Pressman (2021), uma metodologia genérica em Engenharia de software engloba cinco atividades essenciais:

• Comunicação: essencial para compreender os objetivos do projeto, a comunicação entre os participantes é crucial para definir os requisitos e funcionalidades do software a ser desenvolvido.
• Planejamento: nesta fase, é elaborado um "mapa" ou plano de projeto, detalhando as tarefas técnicas, riscos, recursos, produtos a serem gerados e um cronograma de trabalho para acompanhar o progresso do desenvolvimento do software.
• Modelagem: esta atividade envolve a criação de modelos (como diagramas) para uma melhor compreensão das necessidades do software. Esses modelos são fundamentais tanto para a fase de codificação quanto para a validação do projeto pelos stakeholders.
• Construção: nesta etapa, ocorre a codificação do software (baseada nos modelos desenvolvidos anteriormente). Além disso, são realizados testes para validar os códigos de programação criados.
• Entrega: o software é entregue, seja parcial ou completamente, ao cliente, que realiza testes e fornece feedback. Durante esta fase, adaptações e correções são realizadas no software por um período previamente acordado entre as partes envolvidas.

O desenvolvimento de software exige extenso planejamento, e cada projeto de software é único em sua natureza. Por exemplo, mesmo quando duas universidades solicitam softwares para controle acadêmico, é improvável que os dois softwares resultantes sejam idênticos. Como destaca Pressman (2021), diferentes projetos de software requerem diferentes conjuntos de tarefas e abordagens na modelagem das atividades do processo de software. Os analistas de sistemas selecionam essas tarefas com base nas necessidades específicas e nas características do projeto em questão.

Um conjunto de tarefas define as ações necessárias para atingir os objetivos específicos dentro do processo de desenvolvimento de software. Um exemplo clássico seria o desenvolvimento das interfaces de um sistema. O programador trabalha com base em um conjunto de requisitos para as telas do sistema. Após a conclusão da programação, a qualidade do trabalho do programador é avaliada com base nas especificações fornecidas para o desenvolvimento dessas interfaces. No Quadro 1, está apresentado um possível conjunto de tarefas na fase de Planejamento de um Software e os resultados esperados relativo a estas atividades.

ATIVIDADES DE PLANEJAMENTO DE UM SOFTWARE
FASE	ATIVIDADES	RESULTADOS
Planejamento	Levantamento de requisitos. Especificação dos requisitos. Estimativas de prazos.  Estimativa de recursos.	Documentação do levantamento de requisitos. Documentação da especificação de requisitos. Plano de ação para determinar os prazos. Alocação de recursos para criação do software.

Quadro 1 | Conjunto de tarefas (atividades) na fase de Planejamento de um software. Fonte: adaptada de Werlich (2020, p. 31).

Qualidade do software

A presença de um processo de software em si não assegura automaticamente a qualidade do produto final, nem garante sua entrega dentro do prazo estipulado ou a conformidade total com as funcionalidades solicitadas pelo cliente. A qualidade do software está intrinsecamente ligada aos padrões de qualidade aplicados ao longo dos Processos de Software. Portanto, é crucial estabelecer procedimentos e padrões rigorosos para assegurar a qualidade em cada etapa do processo. Um dos benefícios da modelagem de processos é a oportunidade de revisão e busca por melhorias contínuas antes da conclusão e entrega do software.

É essencial avaliar o processo de software para verificar se ele atende a um conjunto de critérios fundamentais. O processo de software pode ser submetido a uma gama de critérios previamente estabelecidos, que contribuem para assegurar a integração e validação eficazes entre as atividades do processo. Pressman (2021) destaca várias metodologias para a avaliação e melhoria dos processos de software, incluindo SCAMPI, SPICE e ISO 9001:2000 aplicadas especificamente ao software.

A metodologia SCAMPI (Standard CMMI Appraisal Method for Process Improvement), que se alinha com o CMMI (Capability Maturity Model Integration), oferece um modelo de avaliação do processo em cinco etapas: início, diagnóstico, estabelecimento, atualização e aprendizado. Essa abordagem estabelece regras para garantir a objetividade nas avaliações, entre outros aspectos:

• Auxilia na coleta e compilação de evidências através de apresentações, documentação e entrevistas.
• Registra todas as evidências observadas em forma de anotações.
• Transforma as anotações em avaliações de conformidade ou não conformidade, em relação às práticas do CMMI.
• Transforma estas avaliações em observações preliminares.
• Confirma a validade das observações preliminares e as converte em observações finais.

A abordagem SPICE (ISO/IEC 15504) é um padrão internacional que estabelece critérios para a avaliação de processos de software. Seu objetivo é auxiliar as organizações na realização de avaliações objetivas da eficácia dos processos de software. Este método oferece uma estrutura para a avaliação de Processos de Software, que pode ser aplicada em organizações envolvidas na produção de software.

Por outro lado, a abordagem ISO 9001:2000 para software, segundo Pressman (2021), é um padrão genérico que pode ser aplicado a qualquer organização que busque manter um padrão global de qualidade em seus produtos, sistemas ou serviços. Existem diversos modelos de referência que auxiliam na garantia da qualidade do software, incluindo ISO/IEC 9126, ISO 9000, ISO 9001 e ISO/IEC 12207. A ISO 9001 foca na garantia de qualidade em design, desenvolvimento e assistência técnica de projetos. Esta norma é especificamente aplicável ao desenvolvimento, fornecimento e manutenção de software, conforme detalhado na norma ISO 9000-3. Já a ISO/IEC 9126 detalha as características que definem um software de qualidade.

Os erros que surgem durante o processo de software podem ser gerenciados por meio de uma abordagem metodológica cuidadosa. É essencial que os Analistas de Sistemas se mantenham atualizados sobre as novas metodologias, avaliando-as e adotando-as no Processo de Software quando apropriado. O objetivo é desenvolver um software de alta qualidade, com o mínimo possível de erros e que atenda às expectativas do cliente. 

Vamos Exercitar?

Chegou o momento de resolver o desafio que lhe foi proposto no início da aula. O desenvolvimento de um software requer a mobilização de diversos profissionais, cada um contribuindo com sua função. Você, como Analista de sistemas em uma software house, recebeu como missão rever o processo de software da empresa e propor melhorias. Podemos começar essa investigação, fazendo um levantamento das principais atividades de um Processo de software.

Geralmente as atividades de um processo de software estão divididas em: Especificação (Análise), Projeto, Implementação, Validação, Manutenção e Evolução.

Para exemplificar as atividades de um processo de software, veja algumas atividades:

• Especificação: são realizados o estudo de Viabilidade, a Elicitação de requisitos, a Especificação de requisitos e a Validação dos requisitos.
• Projeto: são definidas as estruturas modulares do software, as interfaces gráficas e as estruturas de dados (do banco de dados).
• Implementação: tudo o que foi decidido nas atividades de Especificação e Projeto é passado para uma linguagem de programação e o banco de dados é criado.
• Validação: São realizados testes para validar tanto os códigos dos programas quanto a verificação dos requisitos (se o software atendeu aos requisitos impostos pelo cliente).
• Manutenção e evolução: são atividades contínuas a fim de melhoramento do software e inclusão de novos recursos.

É comum as atividades de Especificação que envolvem todo o processo de busca de informação sobre o software a ser construído funcionarem em paralelo às atividades de Projeto (assim que as funcionalidades do software forem levantadas, já é realizado o Projeto do software), e como não podemos deixar os programadores desocupados, as atividades da Implementação (codificando o software) caminham em paralelo às atividades de Projeto (desde que aprovadas).

Agora que já sabemos quais as principais atividades, podemos pensar em como melhorar o processo de construção de um software. Para isso, pensando na qualidade final dos Processos de Software, é necessário estabelecer uma série de critérios de validação das atividades do Processo de Software, implantando um (ou mais) métodos de abordagem de avaliação e melhoria dos processos, podendo ser: SCAMPI, SPICE e ISO 9001:2000.

Entretanto, você deverá fazer algumas pesquisas para ajudar a sua empresa. Pesquise na Internet:

1. Normas específicas da ISO 9001:2000. Faça um relatório indicando quais itens dessa norma podem ser adotados no processo de software.
2. Novas metodologias ágeis que podem acelerar o desenvolvimento.

Saiba Mais

Existe um modelo de referência de qualidade de software brasileiro, este é chamado de MPS.BR. Conheça mais sobre este modelo:

SOFTEX. Modelos de referência. [s. d].

Leia mais sobre a modelos de processo e definição de atividade no livro Engenharia de software, em Capítulo 2, seção 2.1 e 2.2, disponível na Biblioteca Virtual:

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Grupo A, 2021.

O livro Engenharia de Software – Projetos e Processos, Capítulos 1, 2 e 3 aprofundam bastante o tema estudado nesta aula.

FILHO, W. de P. P. Engenharia de Software - Projetos e Processos - Vol. 2. Grupo GEN, 2019

Referências Bibliográficas

ENGHOLM JR., H. Engenharia de Software na Prática. São Paulo: Novatec, 2010. 

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021. 

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018. 

WERLICH, C. Análise e modelagem de sistemas.  Londrina: Editora e Distribuidora Educacional S.A., 2020.

Modelos de processos de software

Olá estudante! Nesta videoaula, você conhecerá o mundo dos modelos de processo, destacando o Scrum, XP e o Modelo Evolutivo. Compreender essas metodologias é crucial para aprimorar sua prática profissional. O Scrum otimiza a gestão de projetos, o XP foca em práticas ágeis, e o Modelo Evolutivo abraça a adaptabilidade. Juntos, esses conhecimentos capacitam você a moldar abordagens eficientes no desenvolvimento de software. Prepare-se para uma imersão prática e transformadora.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

O uso de smartphones vem revolucionando a maneira das pessoas utilizarem softwares. Existem APPs para pagar contas, controlar gastos, localizar lugares e pessoas, e uma infinidade de outras utilidades. Nesse universo, dois grandes sistemas operacionais se destacam, o Android e o iOS. Você sabia que para desenvolver um software (APP) nativo para esses dois sistemas é preciso utilizar diferentes linguagens de programação? Ou seja, para um mesmo APP nativo, são necessários dois projetos de desenvolvimento e duas equipes. Com tanto trabalho, como isso pode ser feito de maneira organizada, controlada e eficiente? Só há uma maneira! Usando um modelo de processo de software que seja adequado ao projeto, à equipe e às expectativas do cliente.

Nesta aula, exploraremos diversos modelos de processos de software disponíveis no mercado. Alguns desses modelos são antigos, mas ainda são amplamente utilizados em vários projetos. A escolha do modelo adequado depende do tipo de software a ser desenvolvido e das expectativas do cliente. O objetivo de todos esses modelos é evitar o caos no desenvolvimento e estabelecer um fluxo de trabalho eficaz.

Imaginemos que você é um analista de sistemas trabalhando em uma software house e acaba de receber um novo cliente. Este cliente deseja desenvolver um software para sua loja de brinquedos online, que permita aos usuários comprar produtos. Além do site, é necessário criar um aplicativo para compras e aluguel de brinquedos, sendo que a opção de aluguel estará disponível apenas no app.

Agora, você enfrenta a decisão crucial: qual modelo de processo de software é o mais adequado para este novo projeto?

Vamos Começar!

Os Modelos de Processos de Software são utilizados para gerenciar as atividades envolvidas no desenvolvimento de software. O objetivo de um modelo de processo de software é fornecer um framework estável, controlado e organizado para essas atividades. Geralmente representado de forma gráfica, um modelo de processo de software detalha os objetos e atividades que fazem parte do processo de desenvolvimento. Pfleeger (2004) aponta que há uma variedade de técnicas e ferramentas disponíveis para a Modelagem de Processos e que não existe um modelo universalmente aceito como o melhor. Cada empresa adota e adapta um modelo de processo de software de acordo com suas necessidades específicas e os requisitos de cada projeto de software.

Pressman (2021) enfatiza que um modelo de processo de software serve como um roteiro para as atividades de Engenharia de software, delineando o fluxo de atividades, ações e tarefas, bem como o grau de interação entre elas, os artefatos a serem produzidos e a organização do trabalho a ser realizado. Há vários modelos de processos de software, cada um com suas próprias características distintas. Alguns dos mais notáveis incluem modelos de processos prescritivos, modelos de processos especializados e modelos de desenvolvimento ágil. 

Modelos de processos prescritivos

O modelo de processo prescritivo, também conhecido como modelo de processos tradicionais, é definido por um conjunto de elementos do processo, que incluem ações de engenharia de software, produtos resultantes do trabalho e mecanismos de garantia de qualidade e controle de mudanças em projetos de desenvolvimento de sistemas de software, conforme descrito por Pressman (2021). Este modelo estabelece as relações entre os elementos do processo com o objetivo de organizar e estruturar o desenvolvimento de um software de maneira ordenada.

Neste modelo, as tarefas são realizadas de forma sequencial e com diretrizes claras. Elas delineiam um conjunto de atividades metodológicas, ações, tarefas, artefatos, medidas de garantia de qualidade e mecanismos de controle de mudanças para cada projeto. Cada Modelo de processo prescritivo também define um fluxo de processo (ou fluxo de trabalho), descrevendo como os elementos do processo estão interconectados.

Dentre os modelos de processos prescritivos mais conhecidos estão o modelo cascata, o modelo Incremental, os modelos evolucionários (que incluem prototipação e espiral) e os modelos concorrentes.

O modelo cascata, também conhecido como ciclo de vida clássico de um sistema ou abordagem Top-down, caracteriza-se por sua abordagem sistemática e sequencial para os processos de desenvolvimento de software. Neste modelo, cada fase do projeto começa somente após a conclusão da fase anterior, enfatizando uma progressão linear e estruturada. A Figura 1 ilustraria este modelo, mostrando como ele flui de uma etapa para a próxima de maneira ordenada e previsível.

A Figura 1 destaca os estágios do modelo cascata com as cinco atividades fundamentais deste modelo. Vejamos a definição dessas cinco etapas segundo Sommerville (2018):

• Definição de requisitos: nesta etapa, as funcionalidades do sistema são definidas através de consultas aos usuários. A especificação do sistema é documentada, envolvendo a participação e a aprovação do cliente para garantir que as necessidades sejam atendidas.
• Projeto do sistema de software: esta fase inclui o planejamento da estrutura do sistema, designando recursos para o desenvolvimento do software. Aqui, são definidas a estrutura de dados, a arquitetura do software, interfaces gráficas, entre outros aspectos técnicos.
• Implementação e teste de unidade: durante a implementação, o software é codificado na linguagem de programação escolhida. Paralelamente, testes unitários são realizados em cada módulo ou parte do código para identificar e corrigir falhas de programação.
• Integração e teste de sistemas: após a codificação, todos os módulos do software são integrados e submetidos a testes conjuntos, preparando o software para entrega ao cliente.
• Operação e manutenção: com o software em uso, surgem correções e possíveis melhorias solicitadas pelos usuários. Nesta fase, são implementadas as correções e novos requisitos identificados como necessários pelo cliente, assegurando a funcionalidade contínua e aprimoramento do software.

O modelo em cascata é o mais tradicional e simples dentre os modelos de processos de software, oferecendo uma estrutura clara para as atividades e servindo de base para outros modelos que surgiram posteriormente. Sua simplicidade e clareza tornam o gerenciamento mais fácil. No entanto, este modelo pode prolongar o tempo de desenvolvimento de um software, especialmente em projetos complexos, devido à sua natureza sequencial, onde atrasos em uma fase afetam as subsequentes. Como resultado, os clientes podem enfrentar longos períodos de espera antes de receberem o produto final, o que pode levar à insatisfação. Além disso, o modelo em cascata normalmente conta com uma única fase de especificação de requisitos. Uma alternativa para mitigar essas limitações é o uso do modelo incremental.

O modelo incremental é iterativo e constrói o software em etapas. A partir dos requisitos iniciais, pequenas versões do software são desenvolvidas e entregues ao cliente, expandindo-se progressivamente até a construção completa do sistema ideal. Neste modelo, cada versão representa um incremento, incluindo parte das funcionalidades requisitadas. Diferentemente do modelo em cascata, no modelo incremental o cliente recebe o software em várias entregas parciais ao longo do desenvolvimento. Essas entregas consistem em módulos que adicionam ou aprimoram as funcionalidades do sistema. Cada incremento é lançado como uma nova versão do software, culminando na versão final. A Figura 2 ilustra o modelo incremental, mostrando que as atividades de especificação, desenvolvimento e validação ocorrem de forma intercalada, não separadamente. Segundo Sommerville (2018), é essencial manter um feedback rápido entre as atividades simultâneas. Em cada incremento, o ciclo completo de desenvolvimento de software é realizado, do planejamento aos testes, resultando em um sistema funcional, mesmo que ainda incompleto em termos de requisitos.

O modelo espiral, apresentado na Figura 3, uma variante do modelo evolutivo, combina a natureza iterativa da prototipação com os elementos sistemáticos e controlados do modelo cascata, conforme descrito por Pressman (2016). Este modelo visa o desenvolvimento acelerado de versões do software, onde cada ciclo iterativo resulta em uma versão mais avançada e completa do produto.

Siga em Frente...

Modelo de processo especializado

Os modelos de processos especializados combinam elementos de um ou mais Modelos de Processos Prescritivos e são aplicados em situações que demandam uma abordagem de Engenharia de Software mais específica e detalhada. Pressman (2021) lista diversos exemplos desses modelos especializados:

• Modelo baseado em componentes: este modelo é frequentemente utilizado em projetos de software comercial, onde componentes de software pré-fabricados são empregados. Tais componentes, vendidos individualmente ou em conjunto, são projetados para reutilização em diversos projetos. Cada componente é uma unidade independente do software e pode ser substituído ou modificado conforme necessário.
• Modelo de métodos formais: este modelo envolve a criação de especificações matemáticas formais do software. Ele ajuda a identificar e eliminar problemas como ambiguidade, incompletude e inconsistência, fornecendo uma base sólida para a verificação de código e a detecção de erros que poderiam passar despercebidos.
• Desenvolvimento de software orientado a aspectos: esta abordagem metodológica define, especifica, projeta e constrói aspectos do software. O código é organizado de acordo com sua importância, com as classes orientadas a objetos sendo um exemplo. Os requisitos são modelados de maneira a abranger várias funcionalidades do sistema.
• Modelo de processo unificado: também conhecido como RUP (Rational Unified Process), este modelo combina características dos modelos prescritivos tradicionais com alguns princípios da metodologia Ágil. É considerado um modelo iterativo e incremental.
• Modelos de processos pessoal e de equipe: esses modelos focam no desenvolvimento de software como um esforço coletivo da equipe. No modelo de processo de software pessoal, a ênfase é na medição individual do trabalho produzido e na qualidade resultante. Já o modelo de processo de software de equipe visa criar uma equipe auto-organizada e autodirigida, com o objetivo de produzir software de alta qualidade.

Modelo de desenvolvimento ágil

Com a evolução constante das tecnologias, os processos de negócios têm exigido um desenvolvimento de software mais ágil e rápido. Diante disso, surgiu a Metodologia Ágil, uma abordagem que introduz maior flexibilidade e dinamismo no desenvolvimento de software.

A Metodologia Ágil foi desenvolvida para abordar certos desafios da Engenharia de software, oferecendo vantagens significativas. Para Sbrocco (2012), essa metodologia responde à necessidade de um desenvolvimento de software mais rápido, em resposta à demanda dos clientes por resultados rápidos e à natureza evolutiva dos aplicativos, que frequentemente incorporam novas funcionalidades. O Desenvolvimento Ágil enfatiza a flexibilidade e a rapidez na atenção às necessidades dos clientes. Outro ponto relevante deste método são as entregas frequentes, com ênfase na comunicação ativa e contínua entre as partes envolvidas, buscando satisfazer o cliente através de entregas incrementais. Os princípios fundamentais do Desenvolvimento Ágil:

• Envolvimento ativo do cliente: é crucial que o cliente participe ativamente no desenvolvimento do software, fornecendo requisitos e avaliando os incrementos desenvolvidos.
• Desenvolvimento incremental: o software é desenvolvido em etapas, permitindo que o cliente forneça novos requisitos que serão incorporados em cada incremento subsequente.
• Foco nas pessoas, não nos processos: a equipe tem autonomia no desenvolvimento, maximizando o potencial dos desenvolvedores, sem a rigidez dos processos prescritivos.
• Flexibilidade para mudanças: o projeto é estruturado de forma a acomodar mudanças nos requisitos, adaptando-se às novas necessidades que possam surgir.
• Simplicidade como chave: a equipe deve evitar complexidades desnecessárias, adotando uma abordagem simples e eficiente em seu trabalho.

O processo de Desenvolvimento Ágil tem como objetivo principal diminuir significativamente a necessidade de documentação extensa. Isso torna o processo de desenvolvimento mais flexível e diminui a burocracia, comum em outros Modelos de Processos de Software. Nesse contexto, destacam-se dois Métodos Ágeis: XP (Extreme Programming) e Scrum.

No Método XP, a retroalimentação constante, o desenvolvimento incremental e a comunicação eficaz entre os envolvidos são aspectos centrais. Pressman (2021) salienta a necessidade de seguir quatro atividades metodológicas principais: Planejamento, Projeto, Codificação e Testes. O desenvolvimento do software segue um padrão, com trabalho em pares e a participação ativa de um representante do cliente no processo, esclarecendo dúvidas e integrando-se à equipe de desenvolvimento.

Por outro lado, a metodologia Scrum aplica um processo de desenvolvimento iterativo e incremental, sendo também aplicável à gestão de projetos. Este método estabelece um conjunto de práticas e regras de gestão visando o sucesso do projeto, como o trabalho em equipe e a comunicação eficaz. Pressman (2021) menciona que o Scrum compreende atividades metodológicas como Requisitos, Análise, Projeto, Evolução e Entrega, cada atividade ocorrem as seguintes tarefas principais:

• Product Backlog: esta é uma lista dinâmica de requisitos e funcionalidades do projeto, com prioridades que podem ser ajustadas a qualquer momento. O gerente do produto é responsável por adicionar, remover e atualizar as prioridades nessa lista.
• Sprints: rstas são unidades de trabalho designadas para atingir objetivos específicos estabelecidos no Product Backlog. Cada Sprint é delimitado por um período fixo, conhecido como Time Box, que define os prazos de entrega.
• Reunião de planejamento de sprint: nessa reunião, o Product Owner define as prioridades dos itens do Product Backlog, e a equipe seleciona as tarefas que consegue implementar no próximo Sprint.
• Daily Scrum: são reuniões diárias e breves, normalmente com duração de 15 minutos, realizadas no início de cada dia de trabalho. Durante estas reuniões, cada membro da equipe responde a três perguntas chave: (i) O que foi realizado desde a última reunião?; (ii) Quais obstáculos foram encontrados?; (iii) O que está planejado até a próxima reunião?

No início de um projeto, são estabelecidas as ideias e funcionalidades básicas do produto, conhecidas como Histórias. Essas Histórias, juntas, compõem o Product Backlog. No método Scrum, as reuniões são frequentemente lideradas pelo Scrum Master, que é responsável por orientar o processo e monitorar o progresso da equipe. O Scrum Master avalia as respostas de cada membro para identificar problemas precocemente, como atrasos ou dificuldades em compreender determinados requisitos. Ao final de cada Sprint, os requisitos definidos são concluídos e sua funcionalidade é avaliada, o que contribui para aperfeiçoar o processo para o próximo Sprint. Cada Sprint finaliza com um avanço no produto ou no Product Backlog.

Além do Scrum, existem outros métodos de Desenvolvimento Ágil. Pressman (2021) menciona métodos como o Desenvolvimento de Sistemas Dinâmicos (DSDM), Modelagem Ágil e o Processo Unificado Ágil. Esses métodos ágeis compartilham uma ênfase na colaboração humana e na auto-organização como componentes fundamentais. 

Vamos Exercitar?

Chegou o momento de resolver o desafio que lhe foi proposto no início da aula! Você é um analista de sistemas e recebeu a missão de determinar qual modelo de processo de software será mais indicado para o mais novo projeto de software. A software house, onde você trabalha, possui um novo cliente que deseja um software para sua loja de brinquedos online. O software deverá permitir que os clientes da loja comprem os produtos disponíveis no site. Além do site, o cliente deseja um aplicativo, caso o usuário queira acessar a loja para comprar ou alugar brinquedos (o aluguel somente estará disponível na versão em aplicativo).

Para responder qual modelo de processo de software será mais indicado para o mais novo projeto de software, antes devemos observar dois detalhes sobre o software a ser desenvolvido: primeiro, o cliente deseja um site (um e-commerce) e, segundo, um aplicativo.

Precisaremos de uma equipe qualificada para realizar o desenvolvimento. A equipe deverá ser subdivida em duas partes: uma para o site e outra para o aplicativo. Há um porém: não foi mencionada qual plataforma deverá ser desenvolvida o aplicativo. Caso considerarmos os sistemas operacionais Android e iOS, deveremos ter uma equipe para cada sistema operacional.

Antes de propor um modelo de processo de software é preciso compreender a complexidade do problema e alinhar os prazos e valores com o cliente. Algumas perguntas que devem ser feitas antes da escolha, são:

1. O cliente tem pressa?
2. A equipe de desenvolvimento é grande o suficiente para trabalhar neste projeto?
3. A equipe domina toda a tecnologia envolvida para o desenvolvimento do site e do aplicativo?

Esse projeto é gigante, visto que o cliente deseja um site e um aplicativo; nesse caso, existe uma grande probabilidade de um modelo baseado nos processos Ágeis ser o mais recomendável, entretanto, a participação do cliente é essencial para o sucesso desta metodologia. Um dos princípios da metodologia Ágil é dividir o software para entregá-lo em partes menores. O cliente não precisa esperar o site e os aplicativos ficarem totalmente prontos para ver o resultado final, mas pode participar ativamente de todo o processo de desenvolvimento.

Uma possível abordagem para esse projeto é adotar a metodologia Scrum. Nessa metodologia, entregas devem ser feitas a cada Sprint; dessa forma o cliente saberá o que vai receber e quando receberá. Os requisitos mais importantes podem ser entregues primeiro possibilitando que tanto o site quanto o aplicativo comecem a operar. Outro ponto importante é a construção do quadro que ajudará a organizar o cronograma e as equipes de trabalho. Veja no Quadro 1 um possível quadro que pode ser usado no projeto. Esse quadro apresenta algumas tarefas pertinentes ao desenvolvi- mento do site. Como podemos observar no Backlog, estão previstas as tarefas Gerar Interfaces do Site (conhecidas como Wireframes), definir a Paleta de Cores do Site, Definir a Estrutura do Banco de Dados.

ATIVIDADES DO BACKLOG
ITENS DO BACKLOG	A FAZER	EM ANDAMENTO	PRONTO
Gerar interfaces do site (wireframes)
Definir paleta de cores
Definir estrutura do banco de dados
...

Quadro 1 | Exemplo de quadro Scrum para o projeto. Fonte: adaptada de Werlich (2020, p.50).

Saiba Mais

Leia mais Modelos de Processos de software no livro Engenharia de Software, Capítulo 2 – Processos de software.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo, SP: Pearson, 2018. 

Gostou do tema Metodologias Ágeis? Quer saber mais sobre o assunto? O livro Metodologias Ágeis aborda esse assunto e apresenta outras metodologias. Acesse os capítulos de acordo com os temas estudados na aula.

SBROCCO, J. H. T. de C.; MACEDO, P. C. de. Metodologias Ágeis - Engenharia de Software sob Medida. Editora Saraiva, 2012. 

Uma boa ferramenta para organizar as tarefas do método ágil Scrum, é o Trello. Esta ferramenta pode ser empregue para criar quadros que representam Sprints, onde listas podem ser usadas para categorizar as tarefas em 'To Do', 'In Progress' e 'Done'. Cada cartão pode representar uma história de usuário ou uma tarefa, e a equipe pode mover estes cartões pelas listas conforme avançam no Sprint. 

Referências Bibliográficas

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

SBROCCO, J. H. T. de C. Metodologias ágeis: engenharia de software sob medida.1. ed. -- São Paulo: Érica, 2012.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

WERLICH, C. Análise e modelagem de sistemas.  Londrina: Editora e Distribuidora Educacional S.A., 2020.

Processo unificado

Olá estudante! Nesta videoaula, você conhecerá o Processo Unificado (PU), destacando suas variantes, como o RUP, e a ferramenta essencial para modelagem, a UML. Compreender esses conceitos é fundamental para aprimorar sua prática profissional, oferecendo uma abordagem robusta no desenvolvimento de software. O PU proporciona estruturação eficiente, o RUP amplia a adaptabilidade, e a UML potencializa a comunicação visual. Prepare-se para uma jornada enriquecedora que impactará positivamente sua atuação no universo da engenharia de software!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, focaremos no Processo Unificado, uma abordagem de desenvolvimento de software que se destaca por ser iterativa, incremental e centrada em arquitetura e casos de uso. O processo unificado é estruturado em quatro fases principais: Concepção, Elaboração, Construção e Transição. Cada fase tem objetivos específicos e contribui para o avanço progressivo do projeto de software. Ao longo da aula, exploraremos detalhadamente essas fases, enfatizando as atividades-chave e os artefatos gerados em cada uma delas. Além disso, discutiremos a importância dos casos de uso como um mecanismo fundamental para capturar requisitos e guiar o desenvolvimento. A abordagem iterativa e incremental permite avaliações e ajustes frequentes, facilitando o gerenciamento de riscos e melhorando a adaptabilidade do projeto às mudanças de requisitos.

A compreensão do processo unificado é crucial para os profissionais de tecnologia, especialmente aqueles envolvidos na gestão de projetos de software. Esta metodologia oferece um framework estruturado que ajuda as equipes a lidar com a complexidade do desenvolvimento de software, ao mesmo tempo em que fornece flexibilidade para se adaptar a mudanças e novos requisitos. O processo unificado apoia uma abordagem de desenvolvimento orientada a resultados, permitindo que as equipes identifiquem e resolvam problemas de maneira eficiente, minimizando riscos e garantindo a entrega de software de alta qualidade.

Imagine que você é um gerente de projeto em uma empresa de desenvolvimento de software. Seu novo projeto é criar um aplicativo de gerenciamento de tarefas pessoais. Utilizando os conceitos do processo unificado, elabore um plano inicial para o desenvolvimento deste software.

No seu planejamento, inclua uma descrição breve de cada uma das quatro fases do processo unificado (Concepção, Elaboração, Construção e Transição) aplicadas ao seu projeto. Especifique quais atividades seriam realizadas em cada fase e que tipo de artefatos (documentos, diagramas, código etc.) você espera produzir. Seu plano deve demonstrar uma compreensão clara do processo unificado e como ele pode ser aplicado para gerenciar efetivamente o ciclo de vida do desenvolvimento de software.

Vamos Começar!

Características do processo unificado

O processo de software refere-se ao conjunto de métodos, técnicas e padrões empregados na produção de software. Dentro da ampla gama de abordagens existentes, o Processo Unificado (PU) se destaca como uma síntese de várias metodologias correlatas. Esta abordagem foi concebida e nomeada como Processo Unificado pelos renomados especialistas em software Jacobson, Booch e Rumbaugh em 2000, que combinaram suas experiências e conhecimentos para criar um modelo de desenvolvimento de software coeso e eficiente.

No processo unificado, um processo define quem está fazendo o quê, quando e como alcançar um determinado objetivo. No PU, os elementos do processo destacados referem-se a:

• Quem (papel) está fazendo.
• O que (artefato).
• Como (atividade).
• Quando (disciplina).

Um planejamento eficaz, fundamentado nos princípios da engenharia de software, é essencial para desenvolver um produto de software de alta qualidade, minimizando os riscos associados ao projeto, incluindo atrasos e custos excessivos. Assim como outros produtos, o software passa por um ciclo de vida que inclui várias fases, desde o início (concepção) até a maturidade e uso completo, e eventualmente chegando ao fim de sua utilidade, como demonstrado em um ciclo de vida típico ilustrado na Figura 1.

É importante que você não confunda ciclo de vida do produto com modelo do ciclo de vida de desenvolvimento. O ciclo de vida do produto engloba quatro fases principais: introdução (ou concepção), crescimento (que inclui o desenvolvimento e a implantação), maturidade e declínio. Por outro lado, o modelo do ciclo de vida de desenvolvimento refere-se à estrutura adotada para gerenciar o processo de criação de um software. Na engenharia de software, vários modelos são utilizados para estruturar o ciclo de vida de desenvolvimento, incluindo o modelo em cascata, espiral, prototipação, incremental e iterativo, entre outros. Estes modelos ajudam a organizar as várias etapas do desenvolvimento de software, desde a concepção até a entrega final.

O modelo em cascata, conhecido por ser um dos mais antigos, é estruturado em cinco etapas principais: (i) análise e levantamento de requisitos, (ii) projeto, (iii) desenvolvimento, (iv) teste e (v) implantação. No modelo incremental, o software é entregue ao cliente em módulos, cada um passando por todas as fases do modelo em cascata. Em contraste, o modelo iterativo ou evolutivo envolve a participação ativa do cliente na fase de análise, mesmo quando todos os requisitos e funcionalidades do software ainda não estão completamente definidos ou a relação entre as atividades não está clara. Inicialmente, realiza-se uma análise básica, seguida da implementação do software. Com o tempo, essa análise é aprimorada, levando à entrega de versões subsequentes e melhoradas do software.

Neste amplo leque de opções de metodologias, destaca-se o Processo Unificado (PU), o tema central desta discussão. O PU é um modelo adaptativo que se inspira no modelo incremental, focando na construção iterativa do software. Este modelo aprimora os processos tradicionais incrementais e iterativos, abordando e mitigando algumas de suas limitações. Por exemplo, no modelo iterativo, há o risco de o software nunca ser concluído devido a constantes solicitações de alterações por parte do cliente, e se a documentação não for bem gerida, o resultado pode ser um software desorganizado. No modelo incremental, a necessidade de completar cada parte integralmente antes de avançar pode ser um entrave. O Processo Unificado, proposto por Jacobson, Booch e Rumbaugh, em 2000, combina os aspectos dos modelos iterativo e incremental, permitindo que o software se desenvolva de forma robusta e coesa, evoluindo gradualmente para a maturidade do processo.

No Processo Unificado (PU), a Linguagem de Modelagem Unificada (UML) é uma ferramenta indispensável, fornecendo um meio eficiente e padronizado para a modelagem de sistemas de software. Como um conjunto de notações gráficas padronizadas, a UML é utilizada para a criação de representações visuais abrangentes dos sistemas, facilitando a visualização, especificação, construção e documentação dos componentes de software. Sua aplicação no PU, um framework adaptativo para o desenvolvimento de software, é fundamental para a comunicação eficaz entre desenvolvedores e demais stakeholders, assegurando que todos os elementos do sistema sejam entendidos e validados antes de sua implementação. Além disso, a UML desempenha um papel chave na organização do processo de desenvolvimento dentro do PU, permitindo a definição clara de requisitos, arquiteturas e componentes do software, bem como o acompanhamento do progresso do projeto através das fases iterativas e incrementais do PU.

O Processo Unificado (PU) foi desenvolvido após a criação da UML, que surgiu da combinação de três metodologias orientadas a objeto: Booch, OMT e OOSE, como destacado por Jacobson no prefácio do livro "El Proceso Unificado de Desarrollo de Software" (JACOBSON; BOOCH; RUMBAUGH, 2000). A UML rapidamente se tornou um padrão na indústria de desenvolvimento de software, mas por si só, não constituía um processo completo para o ciclo de desenvolvimento. Para preencher essa lacuna, a mesma equipe que desenvolveu a UML criou o Processo Unificado Racional (RUP), uma versão mais refinada e detalhada do PU. O RUP, um processo proprietário originalmente desenvolvido pela Rational Software (e mais tarde adquirido pela IBM), foi concebido pelos “três amigos”. Enquanto o RUP é mais detalhado e inclui disciplinas adicionais em comparação ao PU, este último é de domínio público e abrange o ciclo de desenvolvimento de software de forma mais ampla.

Tendo estabelecido uma compreensão inicial do Processo Unificado (PU) no contexto da engenharia de software, vamos agora aprofundar nosso conhecimento sobre esta metodologia significativa. Conforme descrito por Jacobson, Booch e Rumbaugh em 2000, o PU é caracterizado por três aspectos fundamentais: I. orientação por casos de uso, II. foco na arquitetura e III. natureza iterativa e incremental. A seguir, detalharemos cada um desses aspectos essenciais para entender melhor o PU.

1. No Processo Unificado (PU), os casos de uso são elementos centrais, como explicado por Jacobson, Booch e Rumbaugh (2000). Eles são essenciais para entender as necessidades e desejos dos futuros usuários do sistema. É importante que os casos de uso se concentrem nas necessidades específicas de cada usuário, em vez de se limitarem apenas às funções do sistema. Assim, o modelo de casos de uso orienta as fases de projeto (design), implementação e testes do software, seguindo uma sequência lógica de fluxos de trabalho.
2. O segundo aspecto do PU é o foco na arquitetura. Assim como na construção de um carro, onde se considera o design, a mecânica, o sistema elétrico e a aerodinâmica, a arquitetura do software proporciona uma visão geral do sistema. Essa visão abrangente deve incluir tanto as necessidades dos usuários quanto os objetivos estratégicos da empresa, fornecendo ao desenvolvedor um entendimento completo do sistema.
3. O terceiro aspecto, iterativo e incremental, envolve dividir o projeto em subprojetos menores, ou iterações, onde cada uma resulta em um incremento do produto. Jacobson, Booch e Rumbaugh (2000) destacam que "as iterações se referem aos passos no fluxo de trabalho, e os incrementos, ao desenvolvimento do produto". O método iterativo no PU é bem controlado, o que diminui os riscos associados a custos crescentes e prazos estendidos, e acelera o desenvolvimento ao reconhecer que, especialmente em sistemas complexos, é improvável definir completamente os requisitos e necessidades dos usuários no início do projeto. 

Ciclo de vida do processo unificado

O ciclo de vida do PU é uma série de repetições ao longo da vida do sistema, sendo que cada ciclo completo resulta em uma versão do software, por sua vez cada ciclo é composto por 4 fases:

• Concepção: esta fase estabelece a visão geral do projeto, definindo o escopo e os requisitos iniciais. É o momento de determinar os objetivos principais e delinear o que o projeto pretende alcançar.
• Elaboração: aqui, os requisitos e a arquitetura do sistema são detalhados e refinados. Esta fase também envolve uma análise aprofundada dos riscos e a elaboração de estimativas mais precisas para o desenvolvimento do projeto.
• Construção: esta é a fase de desenvolvimento ativo do sistema, onde a construção começa com os elementos mais simples e avança para os mais complexos. Também se inicia a preparação para a implantação do sistema.
• Transição: a última fase do ciclo é dedicada à implantação do sistema, momento em que o software é entregue. Esta fase envolve a finalização dos detalhes para garantir que o sistema esteja pronto para ser usado no ambiente de destino.

Observe, na Figura 2, que o ciclo de desenvolvimento (concepção + elaboração + construção + transição) termina com a entrega de uma versão do sistema, pronta para ser implementada em produção. Todo esse ciclo é composto de muitas iterações, segundo LARMAN (2007).

O Processo Unificado (PU) estrutura-se em torno de quatro elementos fundamentais que definem o processo: o papel (quem), o artefato (o quê), a atividade (como) e a disciplina (quando):

• Papel (trabalhador): define as responsabilidades de cada pessoa envolvida no projeto, especificando as funções e tarefas de cada trabalhador em determinado momento. Um indivíduo pode assumir diferentes papéis e realizar diversas atividades ao longo do projeto.
• Artefato: representa qualquer produto gerado durante o processo de trabalho, que pode incluir código-fonte, esquemas de banco de dados, diagramas, modelos, entre outros. São os resultados tangíveis produzidos pelos trabalhadores.
• Atividade: refere-se às tarefas executadas pelos trabalhadores com o objetivo de criar ou modificar um artefato. Cada atividade é um passo necessário na produção ou alteração de um artefato.
• Disciplina (fluxo de trabalho): envolve a organização das atividades em uma sequência lógica que leva a um resultado significativo. Os fluxos de trabalho são abordados sob três perspectivas: a dinâmica (relacionada ao tempo), a estática (focada nas atividades específicas) e as boas práticas. Dentro de cada perspectiva, existem várias disciplinas que orientam a execução do projeto.

Siga em Frente...

Fluxo de trabalho do processo unificado

As disciplinas fundamentais do Processo Unificado (PU), também conhecidas como fluxos de trabalho, incluem: (i) modelagem de negócios, (ii) requisitos, (iii) análise e projeto, (iv) implementação, e (v) teste e implantação. Estas disciplinas constituem o núcleo principal do nosso estudo. Além delas, existem disciplinas de suporte, como gerenciamento de projeto, gerenciamento de configurações e mudanças, e o ambiente. A Figura 3 ilustra como essas disciplinas são aplicadas durante as fases do ciclo de vida do desenvolvimento e em suas várias iterações. Cada iteração, que representa um minissistema, termina com a entrega de um incremento, momento em que se avalia o cumprimento dos objetivos e se fazem os ajustes necessários. Embora todas as disciplinas possam estar envolvidas em cada iteração, a quantidade de tempo dedicado a cada uma varia. Por exemplo, a Figura 3 mostra que nas primeiras iterações há um foco maior nas fases de concepção e elaboração, enquanto nas iterações finais, outras disciplinas recebem mais atenção, o que reflete a progressão natural no desenvolvimento de um sistema.

Vamos agora analisar o que cada uma destas disciplinas contempla.

1. Modelagem de negócio: esta fase tem como objetivo documentar e analisar os objetivos de negócio envolvidos no projeto, com o intuito de compreender como o negócio deve suportar os processos associados. Embora muitos projetos possam optar por não realizar uma modelagem de negócios detalhada, esta etapa é fundamental para alinhar o projeto do sistema com as necessidades do negócio. Casos de uso de negócios são frequentemente empregados nesta fase para ajudar na documentação e análise.
2. Requisitos: esta fase visa definir claramente o que o sistema deve fazer. Ela se baseia principalmente em casos de uso para identificar os requisitos do sistema. Um aspecto importante nesta etapa é a identificação dos atores, que representam os usuários e quaisquer outros sistemas que interajam com o sistema em desenvolvimento. Conforme um artigo da IBM (2005, p. 4, tradução nossa) indica, é crucial reconhecer todos os atores envolvidos. O foco desta fase está nas funcionalidades do sistema, e é essencial que tanto os desenvolvedores quanto os clientes concordem com a descrição dos requisitos.
3. Análise e Projeto: estas fases são responsáveis pela criação dos modelos do sistema, que servirão de base para futuras implementações. Juntas, elas aprimoram a compreensão dos requisitos funcionais, estabelecidos nos casos de uso. Requisitos funcionais são declarações dos serviços que o sistema deve fornecer, de como ele deve reagir a entradas específicas e de como deve se comportar em determinadas situações. Larman (2005) destaca que a análise se concentra mais na investigação do problema e dos requisitos do que na solução propriamente dita, focando em como o sistema será usado e quais funções ele deve desempenhar, enquanto a implementação lida com o 'como fazer'. Na fase de projeto a atenção é voltada para a concepção da solução, isto é, a criação de modelos que atendam aos requisitos estabelecidos. Esta etapa é direcionada aos desenvolvedores, e não aos usuários finais. Ela envolve a definição clara de subsistemas, com a organização de classes em pacotes, delineando os componentes que serão implementados. Um aspecto crucial do projeto é seu foco na arquitetura do sistema, que implica em representar diversas visões ou abstrações das características mais significativas do sistema. Essa abordagem orientada para a arquitetura facilita a realização de mudanças futuras, especialmente quando os requisitos funcionais passam por alterações, garantindo assim maior flexibilidade e adaptabilidade ao longo do desenvolvimento do software.
4. Implementação: esta fase é dedicada à efetiva construção do software, ou seja, à programação propriamente dita. Aqui, o código é desenvolvido, configurando a parte prática do projeto, onde os desenvolvedores colocam a "mão na massa". A fase de implementação também inclui a preparação para os primeiros testes, conhecidos como testes beta.
5. Testes: nesta etapa, é crucial definir os procedimentos de teste a serem seguidos. Conforme o documento "RUP: boas práticas para o desenvolvimento de software" (IBM, 2005), os principais objetivos dos testes são verificar a interação entre objetos e componentes, assegurar que todos os requisitos foram implementados corretamente e identificar e resolver quaisquer defeitos antes da implantação do software.
6. Implantação: o foco do fluxo de trabalho de implantação é garantir a entrega bem-sucedida do produto aos usuários. Esta fase inclui a aceitação formal do software pelo cliente. As atividades envolvidas na implantação abrangem a distribuição, instalação e migração de dados, bem como a integração com softwares já existentes. Este estágio final assegura que o software esteja pronto para uso no ambiente destinado, atendendo às necessidades dos usuários finais.

As disciplinas adicionais, focadas em suporte, foram integradas no Processo Unificado Racional (RUP) para complementar as áreas não cobertas pelo PU. Estas incluem o gerenciamento de mudanças e configurações, o gerenciamento de projeto e o gerenciamento do ambiente de desenvolvimento. Essas disciplinas são essenciais para alcançar a maturidade do projeto, oferecendo estruturas e processos necessários para gerenciar eficientemente a evolução do projeto, assegurar a qualidade e facilitar a coordenação e execução das tarefas de desenvolvimento. 

Vamos Exercitar?

Chegou o momento de resolver o desafio que lhe foi proposto no início da aula! O plano ilustra a aplicação prática do Processo Unificado no desenvolvimento de um aplicativo de gerenciamento de tarefas pessoais. Cada fase é abordada com atividades e artefatos específicos, demonstrando a abordagem iterativa e incremental do Processo Unificado. Esse planejamento enfatiza a importância da preparação cuidadosa e da resposta flexível às mudanças, elementos-chave para o sucesso no desenvolvimento de software.

1. Fase de Concepção

• Escopo do projeto: definir o objetivo do aplicativo de gerenciamento de tarefas, identificando as necessidades dos usuários e os benefícios esperados.
• Requisitos iniciais: levantar requisitos básicos, como a capacidade de criar, editar e organizar tarefas, definir lembretes e categorizar tarefas.
• Casos de uso principais: desenvolver casos de uso para funções críticas, como adicionar uma nova tarefa, definir prioridades e receber notificações.
• Artefatos: documento de visão, lista inicial de requisitos, casos de uso iniciais.

2. Fase de Elaboração

• Arquitetura do sistema: detalhar a arquitetura do software, escolhendo tecnologias apropriadas e definindo a estrutura de módulos e interfaces.
• Plano de mitigação de riscos: identificar riscos potenciais, como dependências tecnológicas e desafios de integração, propondo estratégias para mitigá-los.
• Artefatos: especificação de arquitetura, modelos de análise e projeto, plano de mitigação de riscos.

3. Fase de Construção

• Desenvolvimento e teste: organizar o desenvolvimento em iterações, com foco na implementação de funcionalidades conforme definido nos casos de uso. Realizar testes contínuos para garantir a qualidade do software.
•  Artefatos: código fonte, testes automatizados, relatórios de teste.

4. Fase de Transição

• Entrega e implantação: preparar o software para lançamento, realizando testes beta com usuários finais e corrigindo quaisquer problemas identificados.
• Treinamento e suporte: desenvolver materiais de treinamento para usuários e estabelecer um plano de suporte pós-lançamento.
• Planejamento de lançamento: definir uma estratégia de lançamento, incluindo comunicação de marketing e cronograma de lançamento.
• Artefatos: versão final do software, manuais de usuário, plano de lançamento. 

Saiba Mais

Leia mais sobre o Processo Unificado no livro Engenharia de Software, Capítulo 2, seção 2.5, disponível na Biblioteca Virtual.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Grupo A, 2021.

O Processo Unificado se baseia na Linguagem de Modelagem Unificada (UML). Para entender mais sobre essa linguagem, acesse o livro UML Essencial, Capítulo 2, disponível na Biblioteca Virtual.

FOWLER, M. UML essencial. Grupo A, 2011.

Ouça o Podcast do Senai Play – Episódio 8 – Processo Unificado, e saiba mais sobre este assunto.

Referências Bibliográficas

IBM. Rational Unified Process: Best practices for software development teams. From the developer Works archives. IBM Staff, jul. 2005.

JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. El Proceso Unificado de Desarrollo de Software. 1. ed. rev. Madrid: Pearsoan Educacion S.A., 2000.

LARMAN, C. Utilizando UML e padrões. 3. ed. São Paulo: Bookman, 2007.

REZENDE, D. A. Engenharia de Software e sistemas de informações. 2. ed. Rio de Janeiro: Brasport, 2002.

Videoaula de Encerramento

Olá, estudante! Nesta videoaula, exploraremos os fundamentos essenciais para o analista de sistemas, mergulhando nos modelos de processo, desde a abordagem ágil até o detalhado Processo Unificado. Compreender esses conceitos é crucial para sua prática profissional, capacitando-o a conduzir análises mais precisas e eficientes. Do dinamismo dos processos ágeis à estrutura do Processo Unificado, esta aula oferecerá insights valiosos para aprimorar suas habilidades e destacar-se como um analista de sistemas exemplar. 

Clique aqui para acessar os slides da sua videoaula.

Vamos começar!

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta Unidade, que é compreender os fundamentos da análise de sistemas e as características dos diversos tipos de processos de software, você deverá primeiramente conhecer os princípios da análise de sistemas.

A análise de sistemas é um processo que envolve estudos detalhados para identificar a solução ideal para o desenvolvimento de um sistema, baseando-se em métodos e técnicas de pesquisa e especificação. Este processo é dividido em várias fases, incluindo análise, projeto, implementação, testes, documentação e manutenção. Cada fase tem um papel específico, desde a avaliação de viabilidade e especificação de funcionalidades até a codificação, teste e documentação do software. Além disso, é importante incluir um processo de homologação para a aprovação oficial do cliente. Sommerville (2018) e Pressman (2021) ressaltam a importância da clareza e compartilhamento de informações, definição progressiva de funcionalidades, ilustração do comportamento do software, estruturação de diagramas em camadas para decompor problemas complexos, e detalhamento dos aspectos de implementação conforme o projeto avança.

Outro ponto importante para se compreender é o papel do analista de sistema. É um profissional responsável por liderar a análise de sistemas, incluindo atividades como pesquisa, planejamento, coordenação de equipes de desenvolvimento e recomendação de soluções de software adequadas às necessidades empresariais. Este papel abrange desde a concepção até a implementação e implantação de software, começando pela definição das funcionalidades do sistema e compreensão das necessidades dos usuários para organização, especificação e documentação adequadas. Este profissional deve ter conhecimentos abrangentes sobre várias áreas de negócios e estar disposto a se informar sobre campos específicos quando necessário. As habilidades importantes para um analista de sistemas incluem estar atualizado com as tecnologias, possuir organização, visão gerencial e excelentes habilidades interpessoais.

O analista de sistemas age como um intermediário entre os desenvolvedores e os usuários finais, coletando e interpretando informações dos usuários para comunicá-las aos desenvolvedores de forma técnica, garantindo que o software atenda às expectativas de clientes e usuários. As responsabilidades do analista de sistemas durante o desenvolvimento de software incluem interagir com clientes e usuários, avaliar a viabilidade do projeto, coletar informações, identificar requisitos, desenvolver modelagem do software, orientar desenvolvedores, realizar testes, gerenciar documentação, administrar mudanças no projeto, estabelecer padrões de desenvolvimento, garantir a qualidade do software, realizar monitoramento e auditorias, organizar treinamentos para usuários, supervisionar a implantação do software e oferecer consultoria técnica. O analista também deve se manter informado sobre novas tecnologias e buscar constante aperfeiçoamento profissional.

Um Processo de software é um conjunto de atividades e resultados inter-relacionados que levam à criação de um software. Segundo Sommerville (2018) e Pressman (2021), na Engenharia de software, esse processo não é uma metodologia rígida, mas sim uma abordagem flexível que permite à equipe de desenvolvimento escolher processos que se alinhem com a filosofia da empresa, buscando qualidade, cumprimento de prazos e redução de custos. O Processo de software geralmente inclui especificação, design, implementação, validação, manutenção e evolução. Esse processo estabelece padrões para a criação de serviços e produtos, facilita a repetição e reutilização de componentes, preserva conhecimento dentro da empresa, define atividades de projetos de software, especifica processos de desenvolvimento, determina tarefas, minimiza riscos, melhora a comunicação na equipe e pode ser usado como modelo para novos projetos.

Engholm Jr. (2010) explica que, ao estabelecer Processos de software, são determinados vários parâmetros, incluindo o evento que inicia o processo, a matriz de responsabilidades, as atividades a serem executadas em ordem, as entradas e saídas de cada atividade, as regras e políticas, a infraestrutura necessária e os resultados de cada processo. Em um Processo de Software, diversas atividades podem ocorrer de forma sequencial ou em paralelo, envolvendo mudanças nas atividades realizadas em cada fase e estabelecendo responsabilidades, prazos e estratégias para alcançar os objetivos. Mesmo variando entre empresas, todos os Processos de software utilizam uma estrutura genérica com atividades pré-estabelecidas.

As etapas fundamentais de qualquer Processo de software são essenciais para desenvolver e entregar um produto de software. De acordo com Sommerville (2018), em um Processo genérico de software, existem quatro atividades chave: Especificação, Projeto e Implementação, Validação e Evolução. A Especificação envolve definir o escopo e funcionalidades do projeto. O Projeto e Implementação abrangem o desenho e a programação do software. A Validação verifica se o software atende aos requisitos do cliente, e a Evolução trata de atualizações e melhorias do software.

Pressman (2021) adiciona que uma metodologia genérica em Engenharia de software inclui cinco atividades essenciais: Comunicação, para compreender os objetivos do projeto; Planejamento, para detalhar tarefas técnicas e cronograma; Modelagem, que envolve criar modelos para entender as necessidades do software; Construção, que é a codificação e teste do software; e Entrega, onde o software é entregue e testado pelo cliente, com adaptações e correções feitas conforme necessário.

Cada projeto de software é único e requer diferentes conjuntos de tarefas e abordagens. Os analistas de sistemas determinam essas tarefas com base nas características e necessidades específicas do projeto. Por exemplo, na criação de interfaces de um sistema, o programador desenvolve as telas com base em requisitos específicos, e a qualidade do trabalho é avaliada conforme essas especificações.

A implementação de um Processo de software não garante automaticamente a qualidade do produto final, nem assegura que o software será entregue dentro do prazo ou que atenderá integralmente aos requisitos do cliente. A qualidade do software depende diretamente dos padrões de qualidade aplicados durante o processo. Estabelecer procedimentos e padrões rigorosos é fundamental para assegurar a qualidade em todas as etapas do processo. A modelagem de processos permite revisões e melhorias contínuas antes da finalização do software.

Existem diversos tipos de modelos de processos de software. O modelo de processo prescritivo, também conhecido como modelo de processos tradicionais, inclui um conjunto de elementos que englobam ações de engenharia de software, produtos de trabalho e mecanismos para garantir a qualidade e controlar mudanças em projetos de desenvolvimento de software. Este modelo orienta o desenvolvimento de software de forma estruturada e ordenada, com tarefas realizadas sequencialmente e diretrizes claras (SOMMERVILLE, 2018).

Dentre os modelos de processos prescritivos mais conhecidos estão o modelo cascata, modelo incremental e os modelos evolucionários, como prototipação e espiral. O modelo cascata é caracterizado por sua abordagem sistemática e sequencial, com cada fase iniciando após a conclusão da anterior. As etapas fundamentais deste modelo incluem definição de requisitos, projeto do sistema, implementação e teste de unidade, integração e teste de sistemas, e operação e manutenção. Este modelo é conhecido por sua simplicidade e clareza, facilitando o gerenciamento, mas pode prolongar o tempo de desenvolvimento devido à sua natureza sequencial.

O modelo incremental, por outro lado, é iterativo e desenvolve o software em etapas. Com base em requisitos iniciais, são criadas versões menores do software, entregues ao cliente de forma progressiva até a conclusão do sistema. Cada versão incremental adiciona ou melhora funcionalidades, oferecendo entregas parciais durante o desenvolvimento.

O modelo espiral combina a abordagem iterativa da prototipação com a estrutura sistemática do modelo cascata. Cada ciclo iterativo no modelo espiral resulta em uma versão mais completa do software, visando um desenvolvimento rápido e eficiente.

Esses modelos prescritivos são essenciais para organizar e estruturar o desenvolvimento de software, oferecendo diferentes abordagens dependendo das necessidades específicas do projeto.

Os modelos de processos especializados representam uma fusão de elementos de diferentes modelos de processos prescritivos, adaptados para situações que exigem abordagens mais específicas e detalhadas. Um exemplo é o modelo baseado em componentes, amplamente usado em projetos comerciais, onde se utilizam componentes de software pré-fabricados para reutilização. Outro modelo, o de métodos formais, concentra-se em criar especificações matemáticas formais para o software, facilitando a eliminação de ambiguidades e inconsistências e fortalecendo a verificação do código.

Além disso, o desenvolvimento de software orientado a aspectos organiza o código por importância, abordando diversos aspectos do sistema, como classes orientadas a objetos. O modelo de processo unificado, ou RUP, integra características dos modelos prescritivos com a metodologia Ágil, sendo iterativo e incremental. Por fim, há o modelo de processos pessoal e de equipe, que enfatiza o desenvolvimento de software como uma atividade coletiva, com foco na medição individual do trabalho no modelo pessoal, e na criação de equipes auto-organizadas e autodirigidas no modelo de equipe, visando a produção de software de alta qualidade.

A evolução constante das tecnologias e dos processos de negócios tem impulsionado a necessidade de um desenvolvimento de software mais ágil e rápido, levando ao surgimento da Metodologia Ágil. Esta abordagem traz maior flexibilidade e dinamismo ao processo de desenvolvimento de software, focando na rapidez e flexibilidade para atender às necessidades dos clientes. A Metodologia Ágil é caracterizada por envolver ativamente o cliente no desenvolvimento, adotar uma abordagem de desenvolvimento incremental, dar autonomia à equipe, ser flexível às mudanças e buscar simplicidade no trabalho.

A Metodologia Ágil visa reduzir a necessidade de documentação extensiva, tornando o processo de desenvolvimento mais flexível e menos burocrático. Dois métodos ágeis se destacam: XP (Extreme Programming) e Scrum. O método XP enfatiza a retroalimentação constante, desenvolvimento incremental e comunicação eficaz, seguindo atividades metodológicas como planejamento, projeto, codificação e testes, com a participação ativa de um representante do cliente (PRESSMAN, 2021). Já o Scrum é um processo de desenvolvimento iterativo e incremental, aplicável também à gestão de projetos, e incorpora práticas e regras de gestão para o sucesso do projeto. Inclui atividades como a definição de uma lista de requisitos (Product Backlog), sprints para atingir objetivos específicos, reuniões de planejamento e reuniões diárias (Daily Scrum) para monitorar o progresso.

Além destes, existem outros métodos de Desenvolvimento Ágil, como o Desenvolvimento de Sistemas Dinâmicos (DSDM), Modelagem Ágil e o Processo Unificado Ágil, todos compartilhando uma ênfase na colaboração humana e na auto-organização.

O Processo Unificado (PU) representa uma abordagem adaptável no desenvolvimento de software, caracterizado por sua natureza iterativa e incremental. A intenção do PU é alinhar o processo de desenvolvimento com os objetivos específicos de cada projeto, mantendo ao tempo a flexibilidade e a eficiência. Uma das características distintas do PU é sua divisão do projeto em mini fases ou iterações, onde cada uma resulta em um incremento do software. Isso permite fazer ajustes contínuos com base no feedback e nas mudanças de necessidades do projeto (ENGHOLM, 2010).  O PU é fortemente centrado em casos de uso para definir os requisitos funcionais, guiando o desenvolvimento pelas necessidades dos usuários finais para assegurar a relevância e utilidade do software. Além disso, a abordagem dá grande ênfase à arquitetura do software, garantindo que o sistema seja robusto, escalável e fácil de manter.

No que diz respeito às fases do PU, ele se divide em quatro etapas principais. A fase de concepção estabelece a visão e o escopo do projeto, focando em identificar requisitos básicos, riscos potenciais e a viabilidade do projeto. A fase de elaboração detalha os requisitos e define a arquitetura base do sistema, além de avaliar os riscos principais, sendo crucial para o planejamento detalhado do projeto. Na fase de construção, o software é desenvolvido e testado, seguindo o design e a arquitetura previamente definidos, resultando em um produto quase final ou versão beta. A fase final, transição, é onde o produto é entregue aos usuários finais, envolvendo a resolução de quaisquer problemas identificados, ajustes finais e, em alguns casos, treinamentos para os usuários e a manutenção do sistema.

Dentre as metodologias derivadas do PU, destaca-se o Rational Unified Process (RUP), desenvolvido pela Rational Software e mais tarde adquirido pela IBM. O RUP personaliza o PU para fornecer um processo mais estruturado e detalhado, adaptando-se a uma variedade de projetos de software (IBM, 2005).

O PU é especialmente benéfico em projetos grandes e complexos, onde os requisitos podem mudar com o tempo. A natureza iterativa e incremental do PU facilita a gestão de riscos, adaptação a mudanças e promove uma colaboração eficaz entre equipes de desenvolvimento e partes interessadas.

É Hora de Praticar!

Scrum e Processo Unificado representam duas abordagens distintas, porém complementares, no vasto cenário do desenvolvimento de software. O Scrum, uma metodologia ágil, destaca-se por sua flexibilidade e capacidade de se adaptar a mudanças rápidas, dividindo o trabalho em iterações mensuráveis chamadas sprints. Por outro lado, o Processo Unificado oferece uma estrutura mais estruturada, dividindo o desenvolvimento em fases definidas, como concepção, elaboração, construção e transição. Embora essas abordagens possam parecer contrastantes à primeira vista, a combinação equilibrada de elementos do Scrum e do Processo Unificado pode resultar em uma metodologia híbrida que aproveita o dinamismo ágil e a solidez estruturada, oferecendo uma abordagem eficaz para projetos complexos. Nesse contexto, exploraremos como essas metodologias podem ser integradas para otimizar o desenvolvimento de software, equilibrando agilidade e estrutura para alcançar resultados sólidos e adaptáveis.

Sabendo disso, vamos imaginar que você é um consultor encarregado de liderar uma equipe de desenvolvimento em um projeto altamente complexo que exige inovação e adaptabilidade. Proponha uma estratégia que combine elementos das metodologias ágeis, como o Scrum, com o processo unificado, enfatizando como essa abordagem híbrida pode gerenciar eficientemente mudanças constantes nos requisitos, garantindo ao mesmo tempo uma arquitetura sólida e escalabilidade para o sistema. Apresente um plano de implementação detalhado, considerando possíveis desafios e soluções, destacando como essa sinergia entre ágil e processo unificado pode ser uma vantagem competitiva no desenvolvimento de projetos de alta complexidade.

Reflita

• Como o papel do analista de sistemas evolui diante das rápidas transformações tecnológicas e das demandas crescentes por inovação nas organizações?
• Qual é a importância de considerar as características específicas de um projeto de software ao escolher o processo de desenvolvimento, e como as necessidades e requisitos únicos podem influenciar a decisão entre metodologias tradicionais, como a cascata, e abordagens ágeis, como o Scrum?
• Como a abordagem do processo unificado na modelagem de software, ao desafiar a segmentação tradicional de fases, contribui para uma visão mais fluida e interconectada, influenciando positivamente na criação de sistemas mais adaptáveis e robustos?

Dê o Play!

Clique aqui para acessar os slides do Dê o play!

Resolução do estudo de caso

Para implementar essa abordagem híbrida de Scrum com o processo unificado, o consultor poderia iniciar adotando sprints do Scrum para iterativamente desenvolver funcionalidades, enquanto, simultaneamente, a fase de Elaboração do processo unificado é utilizada para realizar análises detalhadas de requisitos e arquitetura. Durante os sprints, a equipe aplicaria princípios ágeis de flexibilidade e entrega contínua, enquanto a fase de Elaboração garantiria a estabilidade arquitetural e a integração consistente de novas funcionalidades. Desafios potenciais podem incluir a sincronização eficiente entre as práticas ágeis e tradicionais, que podem ser superados por uma comunicação clara e colaborativa entre as equipes envolvidas. A sinergia resultante entre Scrum e o processo unificado cria um ambiente propício para desenvolver projetos complexos de forma ágil e estruturada. 

Dê o play!

Assimile

Este infográfico oferece uma visão concisa e informativa sobre quatro abordagens fundamentais no desenvolvimento de software: Métodos Ágeis, Método cascata. Scrum e o Processo Unificado (PU). Ao explorar essas metodologias, o infográfico destaca as principais características e benefícios de cada uma. Descubra as práticas ágeis que promovem a flexibilidade e resposta rápida às mudanças, as iterações estruturadas do Scrum para gerenciamento de projetos, e a abordagem iterativa e focada em arquitetura do Processo Unificado.

Referências

ENGHOLM JR., H. Engenharia de Software na Prática. São Paulo: Novatec, 2010.

IBM. Rational Unified Process: Best practices for software development teams. From the developer Works archives. IBM Staff, jul. 2005.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

WERLICH, C. Análise e modelagem de sistemas.  Londrina: Editora e Distribuidora Educacional S.A., 2020.