1. Software Architectural Patterns in Practice: An Empirical Study
Mohamad Kassab
Pennsylvania State University

2. Survey Context, Design and Conduct Lessons Learned and Conclusions
Synopsis
Introduction
Survey Context, Design and Conduct
Statistics Regarding Survey Participants and Projects
How Quality Requirements Satisfaction is Perceived Under Agile Processes?
How Are Quality Requirements Impacting Software Architecture In Practice?
Lessons Learned and Conclusions

3. Introduction [1]
Software systems are characterized both by their functional requirements (FRs) (what the system does) and by their nonfunctional requirements (NFRs) (how the system behaves with respect to some observable attributes like reliability, reusability, maintainability, etc.).
In the software market place, in which functionally equivalent products compete for the same customer, NFRs become more important.
NFRs receive little attention relative to Functional Requirements FRs [WW03].

4. Introduction [2]
There is a rather broad consensus about how to define the term (FR).
A function that a system (…) must be able to perform. [IEEE610.12]
What the product must do. [Robertson99]
What the system should do. [Sommerville04]
FRs describe the behavioral aspects of a system. [Anton 97]
Behavioral requirements are those requirements that specify the inputs to the system; the outputs from the system and behavioral relationship between them; also called functional or operational requirements. [Davis 93]
A requirement that specifies input/output behavior of a system. [Jacobson 99]
Function
Behavior

5. Introduction [3] There is no such consensus for NFRs:
[Chung00]: lists 161 NFRs !!
[IEEE610.12]: Term is not defined. The standard distinguishes design requirements, implementation requirements, interface requirements, performance requirements, and physical requirements.
[IEEE ]: Term is not defined. The standard defines the categories functionality, external interfaces, performance, attributes (portability, security, etc.), and design constraints. Project requirements (such as schedule, cost, or development requirements) are explicitly excluded.
[Anton97]: Describe the nonbehavioral aspects of a system, capturing the properties and constraints under which a system must operate.
[Davis93]: The required overall attributes of the system, including portability, reliability, efficiency, human engineering, testability, understandability, and modifiability.
[Jacobson99]: A requirement that specifies system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability. A requirement that specifies physical constraints on a functional requirement.
[Kotonya98]: Requirements which are not specifically concerned with the functionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet.
[IEEE ] Standard Glossary of Software Engineering Terminology. (1990). IEEE Standard

6. Introduction [4]
[Ncube02]: The behavioral properties that the specified functions must have, such as performance, usability.
[Robertson99]: A property, or quality, that the product must have, such as an appearance, or a speed or accuracy property.
[Wiegers03]: A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable system behavior.
[Wikipedia_NFR]: Requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
[Wikipedia_Requirements Analysis]: Requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
In literature, NFRs are also referred to as :
-ilities: understandability, usability, modifiability, inter-operability, reliability, portability, maintainability, scalability, (re-)configurability, customizability, adaptability, variability, volatility, traceability,…
-ities: security, simplicity, clarity, integrity, modularity, ..
-ness: user-friendliness, robustness, responsiveness, completeness, correctness, cohesiveness, …
Our definition: Umbrella term to cover all those requirements which are not explicitly defined as functional.

7. Introduction [5]: Software Failures !!
1975
National Library of Medicine MEDLARS II system [BI96]
1985
New Jersey Department of Motor Vehicles’ licensing system [Bab85]
1985
Therac 25, Medical Linear Accelerator [Leveson93]
1992
London Ambulance System (LAS) [Finkelstein96]
1997
Mercedes A-Class capsize in corners [Mercedes97]
Mars Climate Orbiter [Breitman99]
1998
2005
Siemens: Possible Hearing Damage in Cell Phones [Siemens05]
Target Credit Cards exposed (40 millions cards !) [Target13]
2013

8. NFRs Impacting Development Effort
Visual Identification of Projects with a Smaller and Higher Unit Cost [Max09].
This is illustrated next with a real data set [Max09] taken from PROMISE DATA repository-(Maxwell) where the project data from one of the biggest commercial banks in Finland was collected. In Figure 6-8, the circles point out some projects that have a large functional size (measured in ISO [ISO ] units: FPA- Unadjusted Function Points) with very little corresponding effort (measured in person-hours). In the same figure, the squares point out some projects that have relatively small functional size with high effort. This illustrates well that a number of other variables (NFRs in this case), in addition to size, must be taken into account to explain individual project effort.

9. Quality Requirements as Architectural Driver
Architectural drivers are requirements that will shape the software architecture
Architectural drivers include:
Software
Architecture
Functional Requirements
Quality Attributes
Constraints

10. Survey Study on Software Quality and Architecture in Practice : Context
Little contemporary data exists to document the actual perception from software experts in industry towards quality requirements for software products.
The key issue in implementing an improvement in industrial practices is to first identify the areas that need the most improvement.
A comprehensive survey of software professionals was conducted to attempt to discover these practices with two objectives:
Remedy the deficiency of lack of data and
To identify the using processes best practices, which can then be disseminated.

11. Survey Study – Design & Conduct [1]
In , we conducted comprehensive anonymous survey study on Software Architecture / Quality State of practice.
The surveys were created as a web-based surveys using the web-based QuestionPro survey tool.
Respondents were asked to base all their project responses on one project only that they were either currently involved with or had taken part in during the past five years.

12. Survey Study – Design & Conduct [2]
Using the conjectures in our hypotheses as means of constructing specific questions, the survey was arranged into 5 sections: project information, criteria and challenges in selecting architectural patterns, impact of the selected pattern on the product quality and project success, organization’s information and participant’s professional information.
Overall, the survey consisted of 19 questions.
Software Architecture,
Techpost Media,
ISMG: Software Architecture and
ISMG Architecture World. An invitation on these groups was posted under the subject Software architecture in practice.
We drew our survey participants from multiple sources but primarily from members of Linked-In professional groups, to which the author belonged.

13. Survey Study – Design & Conduct [3]
1- the average time taken to complete the survey was 10 minutes.
2- We also included the results of the partially completed responses, which have been analyzed following the standard statistical practices [44], particularly revived in medical research [25], taking also into account the specificity of online questionnaires (including the lack of responses or the partial responses), as discussed in details in [51].
3- When respondents aborted the survey, they tended to do so on or near question 15, we speculate from survey fatigue.

14. Survey Participants 45% programmers / developers, 27% as Architects,
18% as Software / System Engineers
10% as product / project / Scrum managers.
Almost 44% of the participants work in small companies (with full time employees).
But also very large companies (with more than 1000 full time employees) are well represented at 30%.
The projects experienced were predominantly of medium to large size in terms of lines of code.
36% of projects contained ( ,000) LOC (medium) and
33% of projects contained (50, ,000) LOC (Large).

15. Project Domains
n = 780

16. Relevant Quality Requirements Per Project Domains: As Relevant
1- performance is of concern in several sectors, not only in embedded systems (like Aerospace or Defense) and in areas requiring high interactivity (Finance and Gaming) as we might have expected, but also in Government, HR, and Marketing, where probably there are “high profile” users of the systems who expect very fast replies.
2- Surprisingly, security appears not so relevant even where we would expect (Medical Systems, Aerospace, Defense), whereas
3- Modifiability, and, somehow, Testability is, perhaps evidencing the process of creating reliable systems by a continuous bug- fixing effort, which, indeed, requires high maintainability.
Areas requiring high interactivity (Finance and Gaming) and the mentioned with “high profile” users also have fairly high values of Availability.
A value in the table presents % of projects from corresponding domain while concerned about corresponding quality

17. How Quality Requirements Satisfaction Is Perceived Under Agile Processes?
Since the inception of agile methods there have been allegations that they increase quality and productivity [Bella13].
Moreover, there are also several empirical studies providing evidences that agile methods and also their individual practices, especially pair programming, may have beneficial effects especially on quality but also on productivity [Coman08] .
However, as also [Bella13] makes clear, there are empirical studies that provide opposite evidences too.
A possibility for generalization comes from statistical metanalysis [Djokic01]. However, metanalysis requires a comprehensive analysis of the original data, and such data is often not fully supplied in the studies.
An alternative approach consists in running a survey and collecting experiences from across a wide variety of contexts, in order to identify the most profitable directions.

18. SDLCs Selected [2016 Data] n = 507
When asked which Software Development Life Cycle process best describes the ones used in the project; the majority of the respondents were aware of the SDLCs used (see Figure 3). Agile development methodologies (e.g. SCRUM, Extreme Programming, Feature Driven Development, Lean) were selected 48% of the time making them the most popular
n = 507

19. Software Development Life Cycles Adopted Within Reported Projects in 2003, 2008 and 2013 Surveys.
43% of respondents indicated in 2013 that they used an agile methodology as a SDLC, comparing to
22% in 2008 and to
only 3% in 2003.

20. Effect of Agile on Software Quality
HP0 (Null Hypothesis): Agile Methods do not have any effect on the quality perceived by the developers of the produced systems.
HP1 (Alternate Hypothesis): Agile Methods have an effect on the quality perceived by the developers of the produced systems.
We define as significant level α for our statistical tests 0.05, as usual in software engineering.

21. Results Of The t-test Showing Statistical Distributions For Each Quality.
Results of the t-test showing statistical distributions for each quality. A positive value of t indicates a higher satisfaction for the quality in the non-agile team
1- As we can observe from the figure, in all criteria the agile situation performs better than the non-agile.
2- quality criteria related to the end user experience (security, usability, and overall quality) appear to be statistically significant at the selected α level, indicating that agile process is particularly suitable to optimize the satisfaction of the end customer for these qualities.
A positive value of t indicates a higher satisfaction for the quality in the non-agile team

22. Software Quality and Productivity [Kassab14]
Reported level of satisfaction on the productivity and final product’s capabilities, qualities (2013 data)

23. How are Quality Requirements Impacting Software Architecture in Practice?
The literature on software architecture suggests one of the primary purposes of the architecture of a system is to create a system design to satisfy the quality attributes [Harrison07] .
The architecture is the first place in software creation in which quality requirements should be addressed.
In fact, if functionality were the only thing that mattered, we wouldn’t have to divide the system into pieces at all, and we wouldn’t need to have an architecture [Bass12].
When designing software architectures, an architect relies on a set of idiomatic patterns commonly named architectural styles or patterns [Kassab12]

24. Which Criteria Were The Most Important in Choosing The Selected Architectural Pattern? [1]
1- speak about these possible answers from NFRs ontology
Total selections counts = 507
n= 207

25. Which Criteria Were The Most Important In Choosing The Selected Architectural Pattern? [2]
Wrong architectural choices can cost significant time and effort in later development, or may cause the system to fail to meet its quality attribute goals.
Out of those who selected quality as a criteria for their patterns selection, 69% reported a level of agreement (either agree or strongly agree) with the statement that the chosen architectural patterns were sufficient to achieve project goals.
The level of agreement among the group whom didn’t select the quality as a criteria was only at 43%.
This highlights the need to improve the current short-sighted practice when selecting architectural patterns.

26. Which Of These Quality Requirements are More Relevant to The Project?
When quality requirements were selected as a criteria, participants identified (on average) three qualities as relevant
n= 183

27. Quality Requirements Co-existence in Surveyed Software Projects
A % in a cell in this matrix means that this is the % of times that the presence of a quality from the corresponding row implies the presence of a quality from the corresponding column (notice that this matrix is not symmetrical).

28. Software Architecture Practices in Software for Medical Devices
If quality requirements are a criteria you considered for choosing an architectural Style, which of these quality requirements were/are more relevant to your project? (Check all that apply)(S2 Survey)

29. Software Architecture Practices in Software for Medical Devices
Despite having usability as a dominant quality of interest, the satisfaction level of the customer with the final project in respect to usability was lower in the medical devices sample (56%) comparing to the level of satisfaction in the overall domains sample (64%).
In-fact, the level of satisfaction was lower for seven out of the eight surveyed qualities in the medical devices sample. The satisfaction level was slightly higher for Testability at 67% comparing to 65% satisfaction in the overall domains sample (See Figure 2).
This finding was a surprise specially when remembering that the medical devices sample utilized agile approaches at a higher rate than the overall domain sample. Recent studies [27] reported that adopting agile methods have a positive effect on the satisfaction level with the quality requirements by the end customer; but it was a surprise to find a counter evidence here.
The satisfaction level of the customer with the projects in respect to the qualities: a) medical devices sample, b) overall domains sample (S2 Survey)

30. Qualities and Architectural Patterns [1]
The architecture of a software system is almost never limited to a single architectural pattern [Microsof09].
Complex systems exhibit multiple patterns at once.
A web-based system might employ a three-tier client-server pattern, but within this pattern it might also use MVC, layering and so forth.
This is consistent with our finding from this survey.

31. Qualities and Architectural Patterns [2]
We presented an extensive list of known architectural patterns that was derived from the representative catalog of patterns which are overviewed in [Bass12].
We asked participants to identify from the list the set of patterns that was selected for their projects.
On average, a respondent indicated that 3 architectural patterns were selected to build the structure of a project.
The average number of employed patterns increases when the size of the project increases (2 for small, 2.4 for medium, and 3.4 for large projects).

32. Which Architectural Patterns Were Selected For the Project?

33. Percentage Of Usage Of Patterns Among Concerned For Quality
1- the percentage of users interested in at least one quality requirement among those who declared to use a given pattern.
2- on the average around 70% of the users of patterns are also interested in a specific quality requirement.
3- This percentage is highest among users of layered and multi-tiered architectures and of brokers and lowest among the users of peer-to-peer, map-reduce, and microservices.
4- The interpretation that we give to this is that those interested in layered, multi-tiered and broker patterns are typically focusing on the design of the system, while those on peer-to-peer, map-reduce, and microservices, are more driven by the desire of getting the results done, perhaps in terms of pure computational results, and this could be especially the case for users of map-reduce.

34. Percentage Of Usage Of Patterns Among Concerned For Quality
1- the “dual” concern of previous figure
2- it expresses the percentage of usage of patterns among those concerned in quality.
3- Here the results are quite univocal: an average of 98% of those concerned for quality use at least one pattern. This percentage varies from almost 100% among those focusing on modifiability to about 95% among those focusing on interoperability.

35. What Degree Did The Final Design of The Project Adhere to The Chosen Architectural Styles? [1]
The architect selects patterns based on their ability to support the majority of the qualities of the system.
Nevertheless, selected patterns (in their standard structures) may not support the entire qualities list.
In order to address the remaining quality requirements architectural tactics can then be incorporated.
Changing the initial structure of the pattern.

36. What Degree Did The Final Design of The Project Adhere to The Chosen Architectural Styles? [3]
The majority (63%) reported that the final design implements the patterns with few changes.
22% reported that that the final design implements the patterns with major changes.
Only 9% reported that the final design implements the patterns with no changes.

37. Software Architecture Practices in Software for Medical Devices
Which architectural styles (patterns) were chosen for the selected project? (Check all that apply) (S2 Survey - Medical Devices Projects sample only) (n=24)

38. Software Architecture Practices in Software for Medical Devices
54% reported that the final design implemented the patterns with major changes or it deviated completely from the chosen patterns
comparing to 22% for the overall domains sample.
46% reported that that the final design implemented the patterns with minor changes for the medical devices
comparing to 63% for the overall domains sample.

39. Conclusions
Quality can be a very elusive concept that can be approached from a number of perspectives dependent on once take.
In this presentation we presented one view of data results based on a survey study conducted on the quality requirements , software architecture state of practice.
web surveys pose significant challenges in terms of the representativeness of the obtained results:
Therefore, our web-based survey was designed according to well designed principles and rules [Trevor13] , [David14] .
To address the problem of representativeness and to increase the external validity of our findings, we drew our survey participants from multiple sources.
It is worth saying that all the studies like this require replications and confirmatory studies, especially in software engineering:

40. Conclusions
In this survey, we focused on findings that are more interesting to us as software engineering experts:
Agile development process have a positive impact on the final qualities of the product.
The majority of the software professionals thought that without patterns it would have not been possible to complete the projects they were involved.
Most of the patterns were applied with changes, however these changes are minor in most of the cases.

41. Conclusions
Architectural patterns are widely used in software projects, with the MVC being the most common followed by client-server and SOA.
The most impelling reason for selecting patterns is the functionality, but software professionals concerned for quality nearly always incorporate patterns. Performance was the first quality requirement selected by software professionals concerned in quality, the second being modifiability, and the third usability.
The most significant difficulty in adopting patterns in practice is the continuous changes of user requirements or of the environment.

42. References
[Abr99]: Abran, A. (1999). COSMIC FFP 2.0: An Implementation of COSMIC functional size measurement concepts. In Proceedings of the 2nd European Software Measurement Conference (FESMA’99), (Oct. 7), Amsterdam.
[Anton97]: A. Antón (1997). Goal Identification and Refinement in the Specification of Information Systems. PhD Thesis, Georgia Institute of Technology.
[AOA04]: Abran, A., Ormandjieva, O., & Abu Talib, M. (2004). Information Theory-Based Functional Complexity Measures and Functional Size With COSMIC-FFP, Proceedings Of The 14th International Workshop On Software Measurement (Iwsm2004), Germany.
[Bab85]: Babcock, C. (1985). New Jersey Motorists in Software Jam, Computerworld, September, 30, (pp. 1- 6).
[Berry03]: Berry, D.M., R. Kazman, R. Wieringa, “Report on the Second International Workshop on From Software Architectures to Architectures (STRAW'03)”, 25th IEEE International Conference on Software Engineering, IEEE Computer Science Press, 2003, pp
[BI96]: Boehm, B., & In, H. (1996). Identifying Quality-Requirement Conflicts, IEEE Software, IEEE Computer Society Press, (pp ).
[Breitman99]: Breitman, K. K, Leite J.C.S.P. and Finkelstein A., “The World’s Stage: A Survey on Requirements Engineering Using a Real-Life Case Study”, Journal of the Brazilian Computer Society. No 1, Vol. 6, Jul pp:13:37.
[Chung00]: L. Chung, B. Nixon, E. Yu, J. Mylopoulos, Non-functional Requirements in Software Engineering, Kluwer Academic Publisher, 2000.
[Cleland-Huang03]: Jane Cleland-Huang, Carl K. Chang, Mark J. Christensen: Event-Based Traceability for Managing Evolutionary Change. IEEE Trans. Software Eng. 29(9): (2003).
[Cleland-Huang 05]: J. Cleland-Huang, R. Settimi, O. BenKhadra, E. Berezhanskaya, S. Christina, “Goal Centric Traceability for Managing Non-Functional Requirements”, Proceedings of the 27th international conference on Software engineering, 2005, pp. 362 – 371.
[COSMIC]: Abran, A., Desharnais, J.-M., Oligny, S., St-Pierre, D. and Symons, C., COSMIC FFP – Measurement Manual (COSMIC implementation guide to ISO/IEC 19761:2003), École de technologie supérieure – Université du Québec, Montréal, Canada, 2003, URL: .
[Daneva05]: Daneva, M., “Architecture Maturity and Requirements Process Maturity Do not Explain Each Other”, Workshop on Software Measurement, German-Canadian Society of Software Metrics, Shaker Verlag, Aachen, 2005.
[Davis 93]: A. Davis (1993). Software Requirements: Objects, Functions and States. Prentice Hall.
[Finkelstein00]: Finkelstein, A., & Emmerich, W., “The Future of Requirements Management Tools In Information Systems in Public Administration and Law”, G. Quirchmayr, R. Wagner and M. Wimmer (Eds.): Oesterreichische Computer Gesellschaft, 2000.
[Finkelstein96]: Finkelstein, A. and Dowell, J., “A comedy of Errors: The London Ambulance Service Case Study”, Proc. 8th International Workshop Software Spec and Design, 1996, pp. 2-5.
[FISMA08]: FISMA, FiSMA 1.1 Functional Size Measurement Method, ISO/IEC 29881,
[HJ02]: Holsapple, C.W. & Joshi, K.D. (2002). A Collaborative Approach to Ontology Design, Communication of the ACM, 45(2), (p.p ).
[ISO ]: ISO (2003). ISO/IEC 20926: Software Engineering - IFPUG 4.1 Unadjusted FSM Method -Counting Practices Manual.
[ISO ]: ISO (2005). ISO/IEC 24570: Software Engineering - NESMA Functional Size Measurement Method v Definitions and Counting Guidelines for the Application of Function Point Analysis.

43. References
[IBM]: IBM website: SAS Hub Non Functional Requirements (NFRs):
[IEEE610.12]: Standard Glossary of Software Engineering Terminology. (1990). IEEE Standard
[IEEE ]:IEEE Std IEEE recommended practice for software requirements specifications, IEEE Transactions o Software Engineering, 1998.
[Jacobson99]: I. Jacobson, G. Booch, and J. Rumbaugh (1999). The Unified Software Development Process. Reading, Mass.: Addison Wesley.
[Kazman05]: Kazman, R., H. P. In: H.-M. Chen, “From Requirements Negotiation to Software Architecture Decisions”, Journal of Information and Software Technology, vol. 47 (9), 2005 pp
[Kotonya98]: G. Kotonya, I. Sommerville (1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons.
[Leveson93]: Leveson, L., and Turner, C.S. “An Investigation of the Therac-25 Accidents” IEEE Computer., 26, 7, (July 1993),
[Mercedes97]: “Mercedes: Wie sicher ist die A-Klasse?“, German news magazine: "Der Spiegel", ISSN , Oct. 27th 1997, p. 120; English translation: last visited on Feb. 11th, 2005.
[Ncube00]: C. Ncube (2000). A Requirements Engineering Method for COTS-Based Systems Development. PhD Thesis, City University London.
[PWL05]: Pfleeger, S. L., Wu, F., & Lewis, R. (2005). Software Cost Estimation and Sizing Methods: Issues and Guidelines, RAND Corporation.
[Robertson99]: S. Robertson and J. Robertson (1999). Mastering the Requirements Process. ACM Press.
[Siemens05]: Siemens Warns of Possible Hearing Damage in Some Cell Phones”, last visited on Feb. 11th, 2005.
[Sommerville04]: I. Sommerville, Software Engineering. 7th edition, Pearson Education, 2004.
[STANDISH09]: Standish Group. (2009). The CHAOS Report, April 23, 2009, Boston.
[UKSMA02]: UKSMA. (2002). Estimating with Mark II,v , ISO/IEC 20968:2002(E),
[Wat06]: Watson, Mike (2006). Managing Smaller Projects: A Practical Approach. Multi-Media Publicaions Inc.. pp. p. 117 ff. ISBN
[Wiegers03]: K. Wiegers (2003). Software Requirements, 2nd edition. Microsoft Press.
[Wikipedia_NFR]: Wikipedia: Non-Functional Requirements (visited ).
[Wikipedia_Requirements Analysis]: Wikipedia: Requirements Analysis /wiki/Requirements_analysis (visited ).
[WW03]: Weber, M., & Wesbrot, J. (2003). Requirements Engineering in Automotive Development: Experiences and Challenges, IEEE Software, 20(1), (pp.16-24).

44. References
[Target13]
[Bass12] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Professional, Boston, MA, USA, 3rd edition, 2012.
[Caring17] P. Lapnate , M. Kassab, N. Laplante, J. Vaous, “Building Caring Healthcare Systems in the Internet of Things:, IEEE Systems, 2017.
[Bella13] Enrico di Bella, Ilenia Fronza, Nattakarn Phaphoom, Alberto Sillitti, Giancarlo Succi, and Jelena Vlasenko. Pair programming and software defects–a large, industrial case study. IEEE Transactions on Software Engineering, 39(7):930–953, 2013.
[Coman08] Irina Diana Coman, Alberto Sillitti, and Giancarlo Succi. Investigating the usefulness of pair-programming in a mature agile team. In International Conference on Agile Processes and Extreme Programming in Software Engineering, pages 127–136. Springer Berlin Heidelberg, 2008.
[Djokic01] Snezana Djokic, Giancarlo Succi, Witold Pedrycz, and Martin Mintchev. Meta Analysis — a Method of Combining Empirical Results and its Application in Object-Oriented Software Systems, pages 103–112. Springer London, London, 2001.
[Kassab14] M. Kassab, “An empirical study on the requirements engineering practices for agile software development”, Software Engineering and Advanced Applications (SEAA), th EUROMICRO Conference, Verona, Italy.
[Harrison07] Neil B Harrison and Paris Avgeriou. Leveraging architecture patterns to satisfy quality attributes. In European Conference on Software Architecture, pages 263–270. Springer, 2007.
[Kassab12] M. Kassab, G. El-Boussaidi, and H. Mili. A quantitative evaluation of the impact of architectural patterns on quality requirements. In Software Engineering Research, Management and Applications 2011, pages 173–184. Springer, 2012.
[Microsoft09] Microsoft Application Architecture Guide (2nded.). MicrosoftPress.
[Trevor13] Trevor G Bond and Christine M Fox. Applying the Rasch model: Fundamental measurement in the human sciences. Psychology Press, 2013.
[David14] David L. Vannette and Jon A. Krosnick. Answering Questions: A Comparison of Survey Satisficing and Mindlessness, pages 312–327. John Wiley & Sons, Ltd, 2014.

45. Thank You ! 45