Revista de Engenharia de Software

No mês passado a editora DevMedia publicou e disponibilizou a primeira edição  da Revista de Engenharia de software, que abordou os seguintes temas:

Introdução a Engenharia de Software;
Engenharia de Requisitos;
Arquitetura de software;
Processos de software;
Gestão de defeitos;

 

O foco dessa edição foi a qualidade de software. De modo geral, os artigos publicados são de boa qualidade, contando com referências, textos bem redigidos e que mostram que foram realmente preprarados e revisados. Além disso,  os textos contam com referências bibliográficas e suplementares sobre o assunto abordado.

O texto da primeira edição está disponível para download no endereço: http://kameha.devmedia.com.br/site/engsoft/es_baixa.zip, sem a necessidade de cadastro ou qualquer mecanismo de controle.

 

Aula: Engenharia de Requisitos – Técnicas de elicitação de requisitos

O de mais importante que ocorreu na aula foi a dinâmica, simulação, de uma entrevista de usuário para elicitação de requisitos. Ficou como sugestão de leitura para a próxima aula, o texto: Uma Taxonomia Facetada para Técnicas de Elicitação de Requisitos, e a pesquisa sobre Joint Application Design (JAD).

Joint Application Design (JAD)

É uma técnica de Desenvolvimento de Aplicações Conjuntas (Joint Application Development) – é uma técnica de coleta de informações que permite a equipe de desenvolvimento e stakeholders, trabalharem juntos para identificarem os requisitos para o sistema de software a ser desenvolvido. Desenvolvida pela IBM no final dos anos 70, ela é um processo estruturado no qual, de 10 a 20 usuários se reúnem sob a direção de um mediador treinado em técnicas JAD. O mediador é quem define a agenda e diretrizes da reunião, no entanto, ele não atua ativamente. Ele deve ser um especialista em técnicas de processos de grupo e em análise de sistemas e de técnicas de projeto. As informações levantadas durantes as seções JAD são registradas por um assistente, que utiliza de ferramentas Computer-Aided Software Engineering (CASE), além de acessórios como: quadro branco, diagramas desenhos a mão livre (storyboard), etc.

Conceitos básicos:

Surgiu em meados de 1970, na IBM

Similar a um Workshop de requisitos

Ocorre na fase de especificação de requisitos

Põe todos os stakeholders juntos por um período intensivo (focado)

Pode utilizar representações de Engenharia de Software

Provê um ambiente para aplicar outras técnicas de elicitação

Facilitador conduz a reunião

Todos têm sua vez de falar

Resultados estão disponíveis imediatamente Papéis:

• Executivo patrocinador:
  • Gerente de nível mais alto comprometido com JAD
  • Patrocina o processo do início ao fim
  • Fornece diretrizes sobre os objetivos e metas de um projeto
  • Define expectativas claras para saída do processo JAD
  • Realiza breve palestra; não participa de atividades das sessões detalhadas, pode ser chamado para esclarecer questões administrativas críticas
• Gerentes funcionais e usuários finais:
  • Peritos em sessões JAD detalhadas
  • Tem a capacidade de descrever porque precisam do sistema
• Representantes da TI:
  • Poucas pessoas
  • Convidadas a participar das sessões
  • Tem conhecimentos técnicos das aplicações atuais do negócio pelo ponto de vista dos sistemas
• Líder de sessão JAD
  • Coração do processo JAD
  • Seu papel é conduzir as entrevistas preparatórias antes da sessão JAD real com o executivo patrocinador e com gerentes funcionais para a definição do escopo básico do processo
• Escribas
  • Registrar oficialmente todas as informações pertinentes ao sistema estudado
  • Sessões maiores – 2 escribas
    • Um descreve os comportamentos do sistema
    • Outro (da mesma área dos usuários) controla questões de negócio levantadas pelos usuários durante a sessão de dinâmica de grupo
  • Uso de ferramentas automatizadas para capturar os requisitos e exibir de volta para os usuários as telas, relatórios, etc.

Processo JAD 

• Quatro etapas:
  • Orientação inicial
  • Familiarização com a área/aplicação
  • Preparação do material para o workshop
  • Workshop

Conclusão: é um tipo de workshop, com processo, papéis e produtos bem definidos. O processo JAD se concentra na sessão JAD, e deste modo JAD contribui para a elicitação de requisitos para validar as informações já colhidas, além de criar novas.

Maiores informações 

Joint application design (JAD) in practice E. J. Davidson   Publisher Elsevier Science Inc.  New York, NY, USA. 

 

Aula: Gestão de projetos – Arquitetura de Software

Hoje a aula de Gestão de Projetos foi direcionada a discussões em torno dos temas: Arquitetura de Software e Ciclo de vidas de diferentes processos de software.

As discussões em torno do tema: Arquitetura de Software limitou-se a definição de arquitetura de software, uma vez que, havia sido solicitados aos alunos do curso, a leitura do capítulo dois da dissertação de mestrado intitulada: Visões em arquitetura de software, da Ane Cristina Varoto, que tem como objetivo apresentar as diferentes definições sobre arquitetura de software.

A autora apresenta a definição dos principais autores pesquisadores do assunto, destacando o livro: Software Architecture. Perspectives on an Emerging Discipline o qual foi o primeiro a formalizar o conceito de arquitetura de software na Engenharia de Software. Dentre as definições a que mais me chamou a atenção foi:

Arquitetura de software são as estruturas que incluem componentes, suas propriedades externas e os relacionamentos entre eles, constituindo uma abstração do sistema. Esta abstração suprime detalhes de componentes que não afetam a forma como eles são usados ou como eles usam outros componentes, auxiliando o gerenciamento da complexidade. [Len Bass, Paul Clements, Rick Kazman; Software Architecture in Practice]”

O texto completo da dissertação da Ana Cristina Varoto está disponível aqui.

Gostaria de ter explorado as discussões sobre arquitetura e estilos arquiteturais, principalmente, quando afirma-se que uma das fases do ciclo de desenvolvimento deve ser a validação da arquitetura, através da realização de um Caso de Uso (UC) arquiteturalmente significativo e que tenha valor para o cliente. No meu entender, essa é uma proposição de difícil realização, uma vez que, a implementação de um UC, pode ser difícil ou apresentar maiores riscos para a equipe de desenvolvimento, seja por falta de conhecimento da equipe com a tecnologia que será utilizada ou qualquer outro motivo, e ele não ser significativo para o cliente. Com isso, seria depreendido tempo na validação de um arquitetura em algo que não é o mas importante para o cliente. Nesse caso o que fazer?

Quanto as discussões sobre o ciclo de vida dos diversos processos de software, os mais citados foram o da Extreme Programming (XP), SCRUM, Unified Process.

Como o foco da disciplina é: Gestão de projetos, ficou faltando discussões sobre os temas:eXtreme Project Management (XPM) e Agile Project Management (APM). Artigos sobre esses temas já foram publicados na Revista MundoPM, da Editora Mundo, na edições 3 e 4 respectivamente.

Modelos de melhoria de processos de software

Hoje a aula Melhoria de processos de software foi apenas para apresentar os modelos de melhoria de processos de software:

• SPICE – ISO/IEC 15504 (Parte 7) – Software Process Improvement and Capability dEtermination
• IDEAL – Initiating, Diagnosing, Establishing, Acting & Learning
  

E o PDCA que apesar de não ser um modelo de software, ele é considerado o meta-modelo do modelos de processos.

Foi apresentado apenas uma visão geral do que trata cada modelo, sendo que não houve nenhum discussão mais aprofundada e objetiva de cada processo.

Para quem quiser saber mais sobre o modelo IDEAL pode baixar o guia de usuário do modelo. IDEAL: A User’s Guide for Software Process Improvement