Projeto, processo e Adaptabilidade do Framework Scrum

Olá pessoal, recebi a pergunta abaixo de um aluno do curso de pós-graduação em Engenharia de Software, nosso MBA da UTFPR-CP.

Como iniciar um projeto SCRUM? Ou seja, o que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Para responder a questão vamos primeiramente definir SCRUM

O Scrum se caracteriza como um framework ágil que possibilita a customização de um processo e que visa a entrega de produtos de forma iterativa e incremental. É baseado em três pilares principais: transparência, inspeção e adaptação.

O Scrum é composto por diversos papéis, incluindo o Product Owner, Scrum Master e a equipe de desenvolvimento, que trabalham juntos para criar um plano detalhado para cada iteração do projeto. Essas iterações são conhecidas como Sprints, que geralmente duram de 2 a 4 semanas.

O Scrum é altamente adaptável e pode ser aplicado a projetos de diferentes tamanhos e complexidades. É amplamente utilizado na indústria de desenvolvimento de software, mas também pode ser aplicado a outras áreas de negócios que envolvem a entrega de produtos ou serviços complexos.

Perceba que o Scrum não é caracterizado como um projeto, Scrum é um Framework adaptável e aplicável a qualquer projeto.

Vamos as questões

Como iniciar o desenvolvimento de um projeto dentro de uma empresa que utiliza Scrum? O que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Tendo como base que a empresa possui um processo institucionalizado a partir do Framework Scrum, você pode realizar uma primeira reunião aplicando a técnica de brainstorming e compilar todas as ideias do projeto em mapa mental (aqui temos o mapeamento de escopo). Posteriormente você também pode delimitar usuários chaves e realizar diversos refinamentos sobre as características do projeto. Neste contexto estamos falando sobre os aspectos ligados a levantamento de requisitos, delineados por várias áreas da engenharia, inclusive a de software. Você pode trabalhar com um termo de abertura de projetos como ponto de partida de um projeto, não existe impedimento para isso.

Eu apresentei uma das formas de delimitar as fronteiras de um projeto (com Mapas Mentais ou com o Termo de Abertura do Projeto). Não iremos, em hipótese alguma, abandonar as práticas da engenharia de software ligadas ao levantamento de requisitos.

Scrum é um framework. Diante deste fato destacar um dos pilares do Scrum, a adaptação. Analise as características do projeto e implemente o work no seu frame. Reflita sobre a amplitude destas palavras. 

O Scrum por si só não é a tábua da salvação, ele necessita de customizações.

Por José Augusto Fabri

A relação entre analista de sistemas e usuários. DevOpS! Correto?

Nós engenheiros de software, analistas de sistemas e desenvolvedores sempre proclamamos a ideia de termos uma relação próxima entre nós e nossos usuários – as (pessoas que manipulam e usam o software). Essa relação, atualmente é chamada de DevOpS.

Vários autores classificam DevOps como uma cultura que aproxima DEsenVolvedores de software (Dev) e os OPeradores de Software (OpS). A ideia central é proporcionar uma comunicação mais clara entre os papéis supracitados. Trabalhar com a automação e monitoramento em todas as fases da construção de software também é algo defendido por vários autores. 

Novamente, ressalto que DevOpS é um nome novo para algo que já fazemos há anos.

A aproximação entre Desenvolvedores e Usuários proporciona a liberação de pacotes de software com o alinhamento mais próximo com os objetivos do negócio da organização. Fato este preconizado pela engenharia de software.

Automatizar o processo de produção de software, capturando as informações sobre a construção do produto também preconizado pelas velhas Fábricas de Software da Década de 1960, fato explicitado por Cusumano em sua obra Japans Software Factories. 

Por fim, às vezes acreditamos que estamos usando um conceito inovador dentro do ambiente produtivo, porém se formos a fundo nos pressupostos da engenharia de software, o conceito já é usado com sucesso há tempos. 

Fica a dica!

por José Augusto Fabri – fabri@utfpr.edu.br 

Referências

Engenharia de Software. http://www.dimap.ufrn.br. Consultado em 26 de julho de 2019.

Pant, Rajiv (17 de março de 2009). Organizing a Digital Technology Department of Medium Size in a Media Company

Samovskiy, Dmitriy (2 de março de 2010). The Rise of DevOps. Fubaredness Is Contagious. Consultado em 19 de março de 2013. 

Arquitetura de software e UML

Arquitetura de software e UML

A arquitetura de software define quais componentes que irão compor as suas propriedades. A forma de relacionamento com os demais softwares e atores também fazem parte da arquitetura.

É possível construir uma tabela que compara alguns itens da arquitetura tradicional com a arquitetura de um software.

Tradicional (casa)	Software
Fachada	Interface
Interior (piso, pintura das paredes, tamanho dos cômodos)	Dados (tabelas, arquivos)
Funcionalidades (formas de iluminação, automatização de portas e janelas, itens de segurança, aquecimento)	Processos (funcionalidades ou requisitos funcionais)

Seguir um padrão arquitetônico é um fato extrema importância que deve ser levado em consideração no desenvolvimento de um software. Ao definir um tipo de revestimento da parede para o um determinado banheiro, você deve replicar o revestimento na totalidade da parede, salvaguardando alguns detalhes inerentes a decoração. O software segue na mesma linha, se você optar por implementar as funcionalidades seguindo o modelo de 3 camadas, você deve adotar o referido modelo como padrão para todas as funcionalidades (uma questão de coerência de desenvolvimento).

O que é o modelo 3 camadas?

O modelo 3 camadas é destinado as aplicações client-server amplamente utilizada no desenvolvimento de software. Esse modelo, quando adotado em uma arquitetura, pode gerar uma maior componentização, proporcionando assim um possível aumento do reuso dos artefatos codificados em um software. Uma maior componentização se traduz em um software mais limpo, fato este que facilita o seu entendimento e manutenção.

O modelo em questão é dividido em:

 

• Camada de interface,
• Camada de regras, negócio,
• Camada de persistência.

 

• Interface = formas de acesso.
• Regras = Algoritmos para tratamento e processamento da informação/dados.
• Persistência = Dados.

 

E a UML possui uma relação direta com o modelo 3 camadas?

Não. A UML é uma linguagem de modelagem, ela pode ser utilizada para especificar diversos tipos de padrões que podem ser instanciados em uma arquitetura de software, incluído o modelo em 3 camadas.

Vamos dar um exemplo.

Partimos do Caso de Uso: Armazenar Dados de Clientes

Utilizando o diagrama de sequência, podemos especificar o caso de uso de várias formas:

Forma 1 – O usuário manipula diretamente os dados.

Forma 2 – O cliente acessa uma interface, informa os dados e os dados são persistidos no objeto cliente.

Forma 3 – O cliente acessa uma interface, informa os dados, os dados são validados por meio de métodos inseridos na classe/objeto de Regras e, por fim, os dados são persistidos no objeto/classe cliente.

A UML foi utilizada para especificar o mesmo caso de uso de 3 formas distintas.

Qual é correta?

Não existe uma forma correta, pois eu não sei nada sobre o seu documento de requisitos, não sei se você trabalhará em um modelo cliente-server e não sei qual tecnologia que você está imerso.

Arquitetura é Arquitetura e UML é UML.

Um abraço a todos.

por José Augusto Fabri.

 

Qual a granularidade de um documento de especificação de um caso de uso?

Esta pergunta foi feita por um aluno do curso de pós-graduação em Tecnologia Java da Universidade Tecnológica Federal do Paraná.

Vamos a resposta.

Eventos, requisitos ou funcionalidades de alta complexidade requerem uma alta granularidade na especificação de requisitos. Neste caso, as especificações (casos de uso) devem ser bem detalhados.

Para eventos, requisitos ou funcionalidades de baixa complexidade, em meu ponto de vista, não é necessário gerar a especificação detalhada.

Por fim, os eventos, requisitos ou funcionalidades de alta complexidade e não detalhados fortemente em sua especificação podem gerar retrabalho e problemas graves durante o desenvolvimento de um software.

A figura abaixo procura apresentar a granularidade de um documento de especificação de requisitos.

por José Augusto Fabri

A Orientação Objeto é Antiga ou Velha?

Um objeto antigo é preservado, pode ser útil em determinadas situações.

Um objeto velho geralmente é descartado.

Você troca o carro velho por um novo.

Você não troca um carro antigo por um novo.

Certamente o carro antigo vale mais que novo.

Dentro dessa linha de pensamento apresento a evolução da OO. Conceito delineado em 375 a.C.

A linha do tempo foi materializada utilizando padlet (padlet.com). Tecnologia esta extremamente útil e várias situações.

por José Augusto Fabri – fabri@utfpr.edu.br

A importância da comunicação, gestão de projetos e configuração (vídeo)

Pessoal,

Compartilho com vocês, por meio de um vídeo, disponibilizado pela ISD, a importância da comunicação e gestão de projetos e configuração no desenvolvimento de software.

Espero que todos aproveitem

Abraços a todos,

José Augusto Fabri – fabri@utfpr.edu.br

Oficina de artigos

Pessoal, eu juntamente com o professor Alexandre L´Erario, formalizamos a aplicação do conceito de oficina de artigos. A oficina tem como objetivo promover o trabalho colaborativo entre pesquisadores de uma determinada área para materializar conhecimento científico.

Esta oficina vem sendo configurada de forma sistemática junto ao GTI,  LabINOV e alunos da área de Engenharia de Software do Programa de Pós-Graduação em Informática da Universidade Tecnológica Federal do Paraná – Campus Cornélio Procópio. Salientamos que a oficina pode ser customizada para qualquer área.

O artigo apresenta os resultados preliminares obtidos com o GTI.

Outra informação importante, é a publicação de 9 artigo dos alunos que cursaram as disciplinas de Engenharia de Software e Experimentação em Computação nos anos de 2012, 2013 e 2014.

O link para acesso a publicação da oficina pode ser obtida por meio deste link.

Se você encontrar dificuldade para realizar o download do artigo, clique aqui.

Boa leitura

J. A. Fabri e A. L´Erario.

 

Aplicando o Mindstorms no ensino de processo e gestão de projetos de software

Pessoal,

Trabalhamos a algum tempo com processo e gestão de projetos de software. Focamos basicamente a implantação e melhoria de processo de software e as áreas chaves da atividade de gestão, principalmente a questão do planejamento do projeto.

Fizemos diversas experiências utilizando o Mindstorms ev3 dentro deste contexto. No mês de outubro, consolidamos um trabalho prático. O trabalho pode ser acessado neste link. O trabalho foi apresentado no IEEE – Frontier Education – Texas – USA.

O vídeo abaixo apresenta o final a aula (de ontem) que utilizou toda a metodologia desenvolvido no trabalho.

Abraços

Fabri e L´Erario.

A relação entre a teoria e a prática no ensino de engenharia

Pessoal, nesta semana me deparei com o um texto Sistemas de Informação e Engenharia de Software: Cadê as Escolas? (Silvio Meira)

De antemão, afirmo que o texto é excelente e concordo os vários pontos relatados.

Ao ler o texto você consegue visualizar rapidamente a relação entre teoria e prática no ensino de engenharia. Ao meu ver, esta relação é apresentada, de forma concisa na figura abaixo.

Perceba que a figura mostra que os docentes imersos no sistema de ensino superior brasileiro são extremamente teóricos (quadrante roxo), fato este que não caracterizo como demérito. O problema encontra-se na capacidade de aplicarmos todo aparato teórico de forma prática, possibilitando a conjunção das ações pesquisar e desenvolver – maximizar a agregação de valor e gerar riqueza de forma sólida e consistente (quadrante vermelho).

Nossa missão é transpor o aluno, imerso no quadrante azul, para o quadrante vermelho. Para cumpri-la devemos nos posicionar neste quadrante. Fato este que não ocorre facilmente, pois esbarramos sempre na base legal que rege as universidades públicas, que impede que os professores se insiram na indústria e obtenham algum retorno. Saliento também que o sistema de avaliação CAPES não colabora com a transposição. O referido sistema, caracterizado como “meritocrático”, qualifica de forma ampla aquilo que chamo de publicação de prateleira (ninguém usa, ninguém lê e não gera valor de forma efetiva). Eu mesmo tenho uma série destas publicações – é meu amigo, são as regras do jogo. Outro fato que colabora com a não transposição dos docentes para o quadrante vermelho é o comodismo, conheço diversos professores que se acostumam com este sistema e são avessos a mudanças.

Por fim, os fatos explicitados no parágrafo anterior nos leva ao fluxo 3 da Figura, na qual o aluno é transposto para o quadrante roxo, ou seja, quando formados são mais teórico e menos práticos. Este fato não possibilita a união das ações pesquisar e desenvolver retratada no quadrante vermelho.

Como mudar esta realidade?

José Augusto Fabri – fabri@utfpr.edu.br

Tecnologia em Análise e Desenvolvimento de Sistemas ou Bacharelado em Engenharia de Software?

Vários alunos me questionam, sistematicamente, sobre as diferenças entre o Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas e o Bacharelado em Engenharia de Software.

Neste post tento enumerar rapidamente algumas.

1 – Curso de Bacharelado e Curso Superior de Tecnologia

O bacharelado, segundo o MEC (Ministério da Educação), é o curso superior que “confere ao diplomado competências em determinado campo do saber para o exercício de atividade acadêmica ou profissional”. Perceba que grifei o termo campo do saber. Esse grifo é proposital e indica que este tipo de curso irá possuir uma carga horária maior, pois o aluno irá mergulhar em todos os conteúdos de um determinado campo do conhecimento.

Os cursos superiores de tecnologia, em sua maioria, possuem 2000 horas. Além do tempo reduzido, eles têm um objeto de estudo bastante específico. Por exemplo: não há um curso tecnológico de jornalismo (campo do saber), mas é possível encontrar um de fotografia (objeto de estudo). Como a carga de conteúdo, neste tipo de curso, é menor e mais centralizada, os estudos são mais focados.

2 – Engenharia de Software ou Análise e Desenvolvimento de Sistemas

Engenharia de Software como campo de saber

Segundo Friedrich Ludwig Bauer “Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe em máquinas reais”.

A Engenharia de Software se concentra nos aspectos processuais (levantamento de requisitos, análise e projeto de sistemas, codificação, teste, implantação, manutenção, gestão de projetos, gestão de configuração e gestão da qualidade).

O termo Engenharia de Software foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Science Committee. Numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos.

Análise e Desenvolvimento de Sistemas como objeto de estudo

Perceba que o curso de Análise e Desenvolvimento de Sistemas se caracteriza como um objeto de estudo da Engenharia de Software. Neste tipo de curso teremos um aprofundamento nas atividades processuais de Modelagem de Negócio, Análise de Sistemas e Programação. As demais atividades do processo de software são encapsuladas em um grupo menor de disciplina.

3 – A diferença das matrizes curriculares e do tempo de integralização (cursos UTFPR – Campus Cornélio Procópio)

Ao analisar as matrizes curriculares dos cursos de Engenharia de Software e Tecnologia em Análise e Desenvolvimento de Sistemas é possível perceber:

• As disciplinas ligadas algoritmos e programação de computadores são equivalentes em ambas às grades;
• quando comparado ao curso de Análise e Desenvolvimento de Sistemas, o curso de Engenharia de Software possui um número maior de disciplinas ligadas à ideia de processo de produção  – veja os quadros grafados em azul nas grades. Dada esta diferença no número disciplina, o curso de Engenharia de Software possui uma carga horária 3250 horas, enquanto que o curso Tecnologia em Análise de Sistemas possui 2582.

4 – Qual curso é melhor?

Os dois cursos possuem um alto grau de excelência, a diferença está no tempo de formação. Para escolher você deve responder as seguintes questões:

Eu quero me aprofundar no campo do saber (engenharia de software) e ficar mais tempo na universidade?

Eu quero me aprofundar no objeto de estudo (análise e desenvolvimento de sistemas) e ficar menos tempo na universidade?

A opção pelo curso de Tecnologia em Análise e Desenvolvimento de Sistemas não inviabiliza que você possa complementar sua formação em outro momento. Para isto você pode cursar as demais disciplinas da Engenharia de Software.

José Augusto Fabri – UTFPR