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:
- 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
Aula: Melhoria de processos de software
Hoje a aula de melhoria de processos de software foi basicamente a leitura do artigo: Software process: a roadmap, do Antonio Fuggetta, que ao contrário do que eu estava imaginando, não ocorreu um debate em torno do tema e dos objetivos do texto.
Um assunto que me chamou atenção, foi a afirmação do professor de que os termos: Metodologia, Processos e Métodos são sinônimos no desenvolvimento de software. Ele apresentou essa afirmação, após eu questioná-lo que ao ele citar a Extreme Programming (XP) e o Scrum como exemplos de processos de desenvolvimento de software não estava ocorrendo um problema de confusão de conceitos de termos diferentes.
Na minha opinião, trata-se de termos conceitualmente diferentes e que me motivou a pesquisar mais mais sobre o assunto.
Processo de Software
O professor da disciplina de Melhoria de processos de software, nos recomendou a leitura do artigo: Software process: a roadmap, e sugeriu que cada pessoa estudasse sobre o tema, utilizando esse artigo como referência inicial.
O trabalho é utilizar pelo menos uma das referências utilizada pelo autor na elaboração do artigo, e um artigo que tenha referenciado esse artigo do Fuggeta. O objetivo desse trabalho segundo o professor, é nos auxiliar a pesquisar artigos científicos, ou no mínimos de fontes mais confiáveis, utilizando as ferramentas adequadas. No caso, o site da ACM, do IEEE e o Scholar da Google.
A tarefa de encontrar os artigo referenciados pelo autor e os que fazem referência a ele é muito simples, pois tanto o Scholar da Google, quanto a ACM já disponibilizam essa informação quando pesquisamos um artigo.
Abaixo, uma apresentação que preparei sobre o tema.
Início das aulas…
Hoje foi primeiro dia de aula do curso, com o professor Zalkind Lincoln Dantas Rocha, que irá ministrar sobre Melhorias de processo de software. Ele iniciou a aula convidando à todos para refletirem sobre a velocidade com que as coisas mudam hoje em dia, e para estimar em quantos anos o conhecimento que iremos adquirir ao longo do curso estará desatualizado, e em algumas situações, não terá valor.
Para isso, ele citou os livros: The Age of Intelligent Machines, The Age of Spiritual Machines: When Computers Exceed Human Intelligence, ambos do Ray Kurzweil.
O tempo da aula foi todo empregado na apresentação individual de cada aluno(a) que tinha de elaborar uma pergunta a ser feita ao professor sobre qualquer coisa.
O que é Engenharia de Software e o que esperar de um curso de Engenharia de Software
Engenharia de Software
Definição
A engenharia de software é uma disciplina da engenharia que relaciona todos os aspectos necessários a produção de software, desde a sua concepção até a sua operação e manutenção, fornecendo todo um arcabouço que abrange um processo, um conjunto de métodos e ferramentas. Para Sommerville, ela é uma disciplina da engenharia tradicional, porque os engenheiros fazem as coisas funcionarem. Eles aplicam teorias, métodos e ferramentas onde for apropriado, mas eles os usam de forma seletiva e sempre procuram descobrir soluções para os problemas, mesmo quando não existem teorias e métodos aplicáveis. Além disso, os engenheiros de software adotam uma abordagem sistemática e organizada em seu trabalho, que é freqüentemente, a maneira mais eficaz de produzir software de alta qualidade.
Para BAUER, A 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 confiável e que trabalhe eficientemente em máquinas reais.
O termo foi criado na década de 60 e utilizado oficialmente em 1968 na NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN). Sua criação surgiu numa tentativa de contornar a crise do software e dar um tratamento mais sistemático e controlado ao desenvolvimento de sistemas de software complexos.
“Na sociedade moderna, o papel da engenharia de software é fornecer sistemas e produtos que melhoram os aspectos materiais da vida humana, tornando assim a vida mais fácil, menos perigosa, mais segura e mais agradável.” (Richard Fairley e Mary Willshire, apud, Pressman, in Software Engineering: a practitioner approach. 6th edition, pp. 2, 2005).
A Engenharia de Software não está relacionada apenas com os aspectos técnicos do desenvolvimento de software, mas também, com as atividades como: gerenciamento de projeto de software e o desenvolvimento de ferramentas, métodos e teorias que apóiem a produção de software.
Dessa forma, podemos definir a Engenharia de software como uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizadas, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software, com o objetivo de auxiliar no processo de produção de software, de forma que o processo de origem a produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor. A Engenharia de software segue o conceito de disciplina na produção de software, fundamentado nas metodologias, que por sua vez seguem métodos que utilizam de ferramentas automáticas para englobar as principais atividades do processo de produção.
Achei interessente a abordagem apresentada no texto: O que é engenharia de software, no qual o autor propõe uma pesquisa no objetivo de obter respostas as seguintes indagações:
- Qual a diferença entre o desenvolvimento de um produto de forma artesanal e o desenvolvimento seguindo os princípios de engenharia? Em outras palavras, qual a diferença entre o trabalho de um artesão e o de um engenheiro?
- Qual a diferença entre cozinhar e fazer engenharia de alimentos?
- O que as diferentes engenharias (civil, mecânica, elétrica/eletrônica, química, ambiental, etc.) têm em comum?
O que esperar de um curso de Engenharia de Software?
O que normalmente espera-se de um curso de especialização em geral é o debate sobre alguma área do conhecimento já estudada ou não durante a graduação, porém com um enfoque mais crítico e mais profundo, do que o apresentado durante a graduação, pois, no caso específico da engenharia de software, que é uma disciplina com carga horária média de 90 horas nos cursos de graduação em Ciência da Computação, o tempo é suficientemente baixo conhecer e estudar as diversas áreas, especialidades, da engenharia.
Por se tratar de um curso de especialização, eu espero aulas mais participativas e menos expositivas, uma vez que, que objetivo do curso é tornar todos os alunos, após a sua conclusão, especialistas em Engenharia de Software.
