Prováveis questões de prova

Prováveis questões de prova compiladas durante a máteria

Questões

1- Discutir "Silver Bullet" (Sucessos e fracassos). Baseado no artigo de Brooks (1986) "No Silver Bullet: essence and accidents of software engineering"

2- Diferença entre Arquitetura de Software e Engenharia de Software. Ler: A technique for software module specification with examples (D. L. Parnas); The Structure of the "THE"-Multiprogramming System (Edsger W. Dijkstra).

3- Analisar a linha do tempo dos artigos, livros e acontecimentos importantes para a arquitetura de SW. Ver artigo: Kruchten et al., The Past, Present, and Future for Software Architecture, IEEE Software. Volume 23, Issue 2 (March 2006) Pages: 22 - 30 Figura 1

4- The Economics of Archtecture-First (Refletir sobre o título do paper) Autor: Grady Booch

5- Arquitetura de Software é estrutura e comportamento. (Refletir sobre a afirmação)

6- Porque os puristas de arquitetura não consideram a UML como uma ADL? ADL - Linguagem de Descrição de Arquitetura.

7- Barry Boehm. A View of 20th and 21st Century Software Engineering. Discutir sobre Green Field e Brown (Ploughed) Field.

8- Escolher um dos 10 conceitos de arquitetura é comentar. Conceitos de Arquitetura

9- Descrever os relacionamentos da arquitetura ANSI-IEEE 1471-2000/ISO/IEC/ 42010 (slide sobre arquitetura).

10- Historia do reuso para as linhas de software (slide de linhas de produto).

11- Reuso é considerada uma bala de prata (Silver Bullet)?

12- Quais os diagramas mais utilizados para o MDE. Analisar o gráfico. Ver figura 3 do artigo: Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure.

Caso de Sucesso - Linha de Produtos

Aluno: Pedro Felipe de Lima

Unnamed

Description: Legal expert systems

Cited Improvements: 
- Increased modifiability, testability, usability (through uniform behavior), and adaptability.

References: C. Fritsch & B. Renz. "Four Mechanisms for Adaptable Systems: A Meta-Level Approach to Building a Software Product Line," R. Nord (ed.), Proceedings SPLC3, Lecture Notes in Computer Science 0302-9743, vol. 3154. Springer, 2004. Page: 34-50. Boston. ISBN: 3540229183. Revised and extended in Software Process Improvement and Practice, v 10, n 2, April-June 2005, 103-24, ISSN: 1077-4866 CODEN: SPIPFL. Wiley, UK. 

Caso de Sucesso - Linha de Produtos

Aluna: Fernanda Gomes Silva

LG Industrial Systems
Description Elevator control systems	Cited Improvements Decreased complexity of software base; functions reduced by half Reduced cost of making changes Reference Klaus Pohl, Günter Böckle, & Frank van der Linden. Software Product Line Engineering, Springer 2005, ch. 21.

Caso de Sucesso - Linha de Produtos

Aluno: Diego Armando de Oliveira Meneses 

Salion, Inc. is a member of the Product Line Hall of Fame.
Description: Revenue acquisition management systems
Cited Improvements:
- Time to market;
- Scalability of product portfolio;

Catálogo de Casos de Sucesso - Linhas de Produto

http://www.sei.cmu.edu/productlines/casestudies/catalog/index.cfm

Cada aluno deve ler e escolher um item de caso de sucesso no uso de linhas de produto, explicar o motivo da escolha de forma sucinta.

Aluno: Josimar de Souza Lima

Sampathgiri Gopalakrishna (Director, Bigtec, Bangalore, India): Software Architecture is a set of answers to the following questions: 

(1) What are the key design decisions that makes it possible to meet the current business requirements? 

(2) What are the key design decisions that makes it possible to overcome the current constraints imposed on the system? 

(3) How does the key design decisions take care of the known future business requirements? 

(4) How does the key design decisions take care of business agility in general to handle unknown future requirements? 

(5) What are the constraints imposed by the software system on business?

Aluna: Fernanda Gomes Silva

Pandu Ranga Rao Masabathula (Senior Developer, International SOS Assistance, Trevose, PA): Software Architecture is an evolving blueprint with artifacts of subsystems/components and the interaction between them and with outside entities/systems. It needs to address the needs of business stakeholders within the organizational, technical and any other constraints to achieve the business, technical or any other goals. It also needs to address software trustworthy characteristics like reliability, availability, maintainability, robustness, safety, security and survivability. A good architecture should continue to support the legacy/current systems and provide a way for enhancements for prospective systems.