Uma introdução ao SWEBOK

Apresentação em tema: "Uma introdução ao SWEBOK"— Transcrição da apresentação:

1 Uma introdução ao SWEBOK
Universidade Federal de Pernambuco Centro de Informática Clarissa César Borba

2 Conteúdo SWEBOK (significado, contexto, motivação, evolução do guia, fases, objetivos, público alvo, princípios) Áreas de Conhecimento Limitações Conclusões

3 SWEBOK Guide to the Software Engineering Body of Knowledge
É uma iniciativa da IEEE Computer Society e tem o propósito de criar um consenso sobre as áreas de conhecimento da Engenharia de Software e seu escopo. O SWEBOK é um guia de uso e aplicação das melhores práticas de Engenharia de Software, informado, sensato e razoável. Ele foi desenvolvido com conhecimentos recolhidos no período de 4 décadas e revisado por inúmeros profissionais de diversos países envolvidos com a Engenharia de Software. Seu principal objetivo foi estabelecer um conjunto apropriado de critérios e normas para a prática profissional da Engenharia de Software. Neste guia, a Engenharia de Software foi dividida em 10 áreas de conhecimentos, também conhecidas por KAs (Knowledge Areas), que serão descritas na seqüência (SWEBOK, 2004).

4 Engenharia de Software
IEEE: “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).” “(1) aplicação de uma abordagem sistemática, disciplinada e quantificável, para desenvolvimento, operação e manutenção do software, isto é a aplicação da engenharia ao software. (2) Os estudos de abordagens como as de (1)”. (PRESSMAN, 2006) Segundo a definição da IEE Computer Society [IEE ], pode-se definir engenharia de software como sendo "a aplicação sistemática, disciplinada, mensurável através do desenvolvimento, operação, e manutenção do software; isto é, a aplicação da engenharia ao software." A Engenharia de Software (ES) surgiu em meados dos anos 1970 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.

5 Contexto Muitos profissionais de Engenharia de Software;
Software como uma realidade na sociedade; Engenharia de Software não reconhecida como uma profissão ou uma disciplina da engenharia;

6 Motivação É uma área de conhecimento em expansão e existem evidências inquestionáveis do seu nível crescente de maturidade: Muitas universidades em todo mundo oferecem curso de graduação em Engenharia de Software. Por exemplo, University of New South Wales (Australia), McMaster University (Canada), the Rochester Institute of Technology (US), the University of Sheffield (UK), etc; O Software Engineering Institute Capability Maturity Model for Software (SW CMM) e o Capability Maturity Model Integration (CMMI) são usados para garantir a capacidade organizacional da Engenharia de Software. O ISO tem sido aplicado na Engenharia de Software pelo novo ISO/IEC 90003;

7 Motivação Continuando...
Association for Computing Machinery (ACM) e a Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) têm desenvolvido e adotado, conjuntamente, um código de éticas e práticas para os profissionais da área; Tanto a IEEE Computer Society quanto o Institute for Certification of Computing Professionals (ICCP) têm oferecido certificação para desenvolvedores e engenheiros de software.

8 Evolução do Guia Começou como uma colaboração entre IEEE CS e ACM;
Foi iniciado em SWECC (Software Engineering Coordinating Committe); Foi gerenciado por: Software Engineering Management Research Laboratory at the Université du Québec Montreal (UQAM) e École de technologie supérieure, Montreal, Québec : From 1993 to 2000, the IEEE Computer Society and the Association for Computing Machinery (ACM) cooperated in promoting the professionalization of software engineering through their joint Software Engineering Coordinating Committee (SWECC). The Code of Ethics was completed under stewardship of the SWECC primarily through volunteer efforts. The SWEBOK project was initiated by the SWECC in 1998. The SWEBOK project�s scope, the variety of communities involved, and the need for broad participation suggested a need for full-time rather than volunteer management. For this purpose, the IEEE Computer Society contracted the Software Engineering Management Research Laboratory at the Universit� du Qu�bec � Montr�al (UQAM) to manage the effort. In recent years, UQAM has been joined by the École de technologie sup�rieure, Montr�al, Qu�bec.

9 Evolução do Guia Participação de diversos stakeholders: indústria, agências de pesquisa, profissionais, autores; Like any software project, the SWEBOK project has many stakeholders�some of which are formally represented. An Industrial Advisory Board, composed of representatives from industry (Boeing, Construx Software, the MITRE Corporation, Rational Software, Raytheon Systems, and SAP Labs-Canada), research agencies (National Institute of Standards and Technology, National Research Council of Canada), the Canadian Council of Professional Engineers, and the IEEE Computer Society, has provided financial support for the project.

10 Fases – Evolução do Guia
Straw Man Protótipo mostrando como o projeto seria organizado Stone Man Mais contribuições Concluído em 2001 Lançado uma versão Trial Iron Man 2 sub-fases Conclusão (2004) The project plan comprised three successive phases: Strawman, Stoneman, and Ironman. An early prototype, Strawman, demonstrated how the project might be organized. The publication of the widely circulated Trial Version of the Guide in 2001 marked the end of the Stoneman phase of the project and initiated a period of trial usage. The current Guide marks the end of the Ironman period by providing a Guide that has achieved consensus through broad review and trial application. The Ironman phase will contain two major sub-phases (contingent on funding): Sub-phase 1 ( ): Experimentation and trial usage of the Guide Promotion of the Guide Development of "performance norms" for software engineering professionals Sub-phase 2 ( ): Development of the Ironman version of the Guide based on the feedback gathered in sub-phase 1 and an extensive review process similar to the review process for the Stoneman phase.

11 Fases – Evolução do Guia
1998 1999 2000 2001 2002 2003 Straw Man Phase Stone Man Phase Experimentation and Trial Usage Iron Man Phase (Sub-phase 1) Revision The project plan comprised three successive phases: Strawman, Stoneman, and Ironman. An early prototype, Strawman, demonstrated how the project might be organized. The publication of the widely circulated Trial Version of the Guide in 2001 marked the end of the Stoneman phase of the project and initiated a period of trial usage. The current Guide marks the end of the Ironman period by providing a Guide that has achieved consensus through broad review and trial application. Iron Man Phase (Sub- phase 2) Trial Version 2004 Version

12 Algumas Estatísticas (Versão 2004)
Revisores registrados: 573 Número de países: 55 Número de revisores que submeteram comentários: 124 Número de países representados: 21 Número de comentários: 1020 The Trial Version of the Guide was the product of extensive review and comment. In three public review cycles, a total of roughly 500 reviewers from 42 countries provided roughly 9,000 comments, all of which are available at To produce the current version, we released the Trial Version for extensive trial usage. Trial application in specialized studies resulted in 17 papers describing good aspects of the Guide, as well as aspects needing improvement. A Web-based survey captured additional experience: 573 individuals from 55 countries registered for the survey; 124 reviewers from 21 countries actually provided comments�1,020 of them. Additional suggestions for improvement resulted from liaison with related organizations and efforts: IEEE-CS/ACM Computing Curricula Software Engineering; the IEEE CS Certified Software Development Professional project; ISO/IEC JTC1/SC7 (software and systems engineering standards); the IEEE Software Engineering Standards Committee; the American Society for Quality, Software Division; and an engineering professional society, the Canadian Council of Professional Engineers.

13 Objetivos Promover uma visão consistente da Engenharia de Software no mundo; Clarear e marcar as fronteiras entre a Engenharia de Software e as outras disciplinas relacionadas; Caracterizar o conteúdo da disciplina de Engenharia de Software; Classificar em tópicos a área de conhecimento da Engenharia de Software; Prover uma fundação para o desenvolvimento do currículo, para certificação individual e para licenciamento de material. Fonte: Wikipedia

14 Público Alvo Organizações públicas e privadas;
Engenheiros de Software; Sociedades profissionais; Corporações de criação de padrões; Estudantes de Engenharia de Software; Educadores e Instrutores;

15 Princípios Transparência Consenso Totalmente livre na WEB
O processo é totalmente documentado e publicado Consenso Indústria Sociedades Profissionais Corporações de criação de padrões Ambientes Acadêmicos Totalmente livre na WEB

16 Áreas de Conhecimento Requisitos de Software Projeto de Software
Construção de Software Teste de Software Manutenção de Software Gerência de Configuração de Software Gerência da Engenharia de Software Processo de Engenharia de Software Ferramentas e Métodos da Engenharia de Software Qualidade de Software The Body of Knowledge is subdivided into ten software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the Knowledge Areas of strongly related disciplines. The descriptions of the KAs are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest.

17

18

19 KA: Software Requirements
“Requisitos são definidos como uma especificação do que deve ser implementado. São descrições de como o sistema deve se comportar, de informações do domínio da aplicação ou restrições nas operações do sistema.” Fonte: Kotonya e Sommerville

20 KA: Software Requirements

21 KA: Software Design Processo de definição da arquitetura, componentes, interfaces e outras características de um sistema ou componente; Tem como base a definição dos requisitos. Conforme o IEEE, design de software é uma atividade que dura por todo o ciclo de vida do software. Trata essencialmente sobre mudança de gerenciamento e da manutenção dos requisitos em um estado que reflete exatamente o software a ser, ou que está sendo, construído. Esta área de conhecimento é dividida em 6 sub-áreas.

22 KA: Software Design

23 KA: Software Construction
Construção de software é um ato fundamental do planejamento de software: Codificação Validação Verificação (testes unitários) Requer que o desenvolvedor seja lógico e preciso; Produz software executável; Uso de Ferramentas para aumento de produtividade e qualidade. SWEBOK – insere o capítulo de construção entre o Design e Testing, porém isto não significa que a construção deva começar depois do design e os testes devam começar apenas depois da etapa de construção. Dependendo do processo escolhido estas atividades podem acontecer em seqüência ou de maneira sucessiva, ou seja, para que uma atividade comece é necessária que uma certa quantidade da atividade anterior seja completada. - Está fortemente ligada às Kas de Design e Testing Construção de software é um ato fundamental do planejamento de software: a construção de software significante que funciona, através de uma combinação de codificação, validação, e verificação (testes unitários). Limites entre desing e construção: Dependendo do tamanho do software a fase de design pode ser requerida com maior interação com a de construção (grandes projetos), ou mesmo não ser requerida, como é o caso de pequenos projetos. Alguns técnicas de software design aplicam-se à construção como por exemplo a divisão de problemas em partes menores Design contém um certo grau de adivinhação e que podem ser corrigido pela construção

24 KA: Software Construction

25 KA: Software Construction
Estilos/Métodos para Construção de Software: Lingüístico Uso de linguagem natural Formal Visual Visual C++ Visual Basic Um segundo e menos importante método de quebrar o assunto da construção de software em unidades menores é reconhecer 3 estilos/métodos de construção de software, ou seja: Linguístico, Formal e Visual.

26 KA: Software Testing Consiste na verificação dinâmica do comportamento de um programa com um conjunto finito de casos de testes, selecionados de um domínio geralmente infinito de execuções, para confirmar o comportamento especificado esperado. Dinâmico: testes implicam em executar programas com valores de entrada, e dependendo do estado do sistema uma mesma entrada pode originar comportamentos diferentes no sistema Finito: apesar do conjunto de teste poder ser considerado infinito, porque o número de execuções que podem ser observadas é finito. Selecionado: utilização diferentes critérios ou técnicas de seleção do conj. finito de testes. Esperado: é possível decidir se as saídas observadas são aceitáveis ou não. Neste último caso, um esforço inútil de teste.

27 KA: Software Testing - A atividade de teste não inicia apenas depois da codificação, mas que pode estar presente durante todo o desenvolvimento de software

28 KA: Software Maintenance
Uma vez em execução, anomalias são descobertas, ambientes de execução são modificados, e novos requisitos do usuário surgem. Uma vez em execução, anomalias são descobertas, ambientes de execução são modificados, e novos requisitos do usuário surgem. A fase de manutenção do ciclo de vida se inicia na entrega mas as atividades de manutenção ocorrem muito antes.

29 KA: Software Maintenance

30 KA: Software Configuration Management (SCM)
Identifica a configuração de um sistema: Controle de mudanças; Manutenção da integridade da configuração durante o ciclo de vida do sistema. Gerencia de configuração de software identifica a configuração de um sistema com o propósito de controlar mudanças na configuração do sistema e manter a integridade da configuração durante o ciclo de vida do sistema

31 KA: Software Configuration Management

32 KA: Software Engineering Management
Corresponde ao gerenciamento, medição e modelagem do desenvolvimento de software. Enquanto é verdade dizer que deveria ser possivel gerenciar software engineering da mesma forma que qq outro processo complexo Existem aspectos particulares para produtos de software e no processo planejamneto(engineering) que complicam bastante o gerenciamanto Incorpora noções de processo e gerenciamento de projeto

33 KA: Software Engineering Management

34 KA: Software Engineering Process
Preocupa-se com: Definição; Implementação; Medida; Gerenciamento; Mudança; Melhoramento. Do próprio processo

35 KA: Software Engineering Process

36 KA: Software Engineering Tools and Methods
Inclui tanto o ambiente de desenvolvimento de software como as áreas de conhecimento de métodos de desenvolvimento. Inclui tanto o ambiente de desenvolvimento de software como as áreas de conhecimento de desenvolvimento de métodos Identificadas na versão straw man do guia Ambiente de desenvolvimento de software- são ferramentas computacionais com o intuito de auxiliar o processo de desenvolvimento De software

37 KA: Software Engineering Tools and Methods

38 KA: Software Engineering Tools and Methods
Ambiente de desenvolvimento de software são ferramentas computacionais com o intuito de auxiliar o processo de desenvolvimento de software. Métodos de Desenvolvimento Impõe estrutura na atividade de desenvolvimento de software, com o objetivo de tornar a atividade sistemática e propícia ao sucesso.

39 KA: Software Quality Presente em grande parte das áreas de conhecimento do guia Este capitulo trata de consideracoes sobre a qualidade de software que transcendem os processos de ciclo de vida

40 KA: Software Quality

41 Disciplinas Relacionadas
Computer engineering Computer science Management Mathematics Project management Quality management Software ergonomics Systems engineering

42 Limitações O guia inclui o conhecimento que é necessário para a Engenharia de Software, mas não suficiente para um engenheiro de software; O guia não cobre assuntos importantes: Linguagens de programação específicas; Banco de Dados específicos; Tecnologias de Redes. 1) Falar que por isso é incompleto. The Guide covers software engineering knowledge that is necessary but not sufficient for a software engineer. Practicing software engineers will need to know many things about computer science, project management, and systems engineering�to name a few�that fall outside the Body of Knowledge characterized by this Guide

43 Limitações Novas tecnologias e práticas surgem com muita freqüência. O guia precisará evoluir junto; O guia proposto não é definitivo, e nem a única fonte de referências; Referências de material em outras línguas foram omitidas.

44 SWEBOK Guide = 10 Knowledge Areas
Mapped TO ISO/IEC 12207:1995 processes Requirements Design Construction Testing Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality Primary Processes Supporting Processes

45 Conclusões Aprovado pelo IEEE Computer Society Board of Governors;
Adotado como ISO Technical Report 19759; SWEBOK Guide 2008? A maioria dos cursos de graduação e pós-graduação tem adotado o SWEBOK como padrão. ISO/IEC TR 19759, which is a Technical Report of type 3, was prepared by the IEEE Computer Society as the Guide to the Software Engineering Body of Knowledge, 2004 Version, and was adopted without change by ISO/IEC JTC 1/SC 7, Software and Systems Engineering. It has also been adopted as a technical report by ISO (ISO/IEC TR 19759). Obviously, a product with this much uptake must be evolved in an open, consultative, deliberate and transparent fashion so that other projects can successfully coordinate efforts. The currently planned strategy is to evolve the SWEBOK Guide using a “time-boxed” approach. The time-box approach is selected because it allows the SWEBOK Guide and coordinating projects to perform revision in anticipation of a fixed date for convergence. The initial timebox is currently planned to be four years in duration. At the conclusion of the time-box, the completed product, SWEBOK Guide 2008, would be reviewed and approved by the Computer Society Board of Governors for publication. If continuing corporate financial support can be obtained, the product would be made freely available on a web site.

46 Referências SWEBOK. Guide to the Software Engineering Body of Knowledge Version. A project of the IEEE Computer Society Professional Practices Committee. Disponível em: Abran, Alain (2004). An international Consensus on the Software Engineering Body of Knowledge. Disponível em: Trial Version SWEBOK. A Project of the Software Engineering Coordinating Committee. Disponível em:

47 Referências The First International Workshop on the Evolution of the Guide to the Software Engineering Body of Knowledge. Edinburgh, Scotland, July 25-28, Disponível em: Rocha, Milena e Oliveira, Jairo. Uma Introdução ao SWEBOK. Disponível em: Rocha, Thayssa. Guide to the Software Engineering Body of Knowledge. Disponível em: Kotonya, Gerald e Sommerville, Ian. Requirements Engineering Processes and Techniques.

48 Perguntas?

49 Uma introdução ao SWEBOK
Universidade Federal de Pernambuco Centro de Informática Clarissa César Borba