Architecture Quality Attributes - Revision history

Suhridk at 14:07, 15 April 2012

2012-04-15T14:07:57Z

2012-04-01T11:21:28Z

Security

2012-03-21T20:10:06Z

Intro

2012-03-21T20:08:14Z

Quality of Architecture

2012-03-21T20:02:41Z

Business Qualities

2012-03-21T19:29:27Z

Reusability

2012-03-21T19:19:39Z

General Scenario

2012-03-21T19:13:45Z

Testability

2012-03-21T19:06:37Z

Portability

2012-03-21T19:05:47Z

Portability

← Older revision		Revision as of 14:07, 15 April 2012
Line 178:		Line 178:
	* Buildability: System needs to be completed by available team in a timely manner and be open to changes.		* Buildability: System needs to be completed by available team in a timely manner and be open to changes.
	** Tasks easily split into development teams.		** Tasks easily split into development teams.
		+
		+	[[Category:SYAR]]

@@ Line 76: / Line 76: @@
 * Security is a measure of the system's ability to resist unauthorized usage while still providing services to legitimate users.
 * Security can be characterized by a system providing:
-** Non-repudiation
+** Non-repudiation : One cannot deny that an action took place.
-** Confidentiality
+** Confidentiality: Data is protected from unauthorized access.
-** Integrity
+** Integrity: Data is delivered as intended, no modification in between.
-** Assurance
+** Assurance: Parties are who they claim they are.
-** Availability
+** Availability: System will be available for legitimate use e.g. DoS will not prevent.
-** Auditing
+** Auditing: System tracks activities.
 === General Scenario ===

@@ Line 2: / Line 2: @@
 * Qualities that must be accommodated in a systems architecture over and above basic functionality.
 * Categories of quality attributes:
 ** Observable attributes. e.g:

@@ Line 169: / Line 169: @@
 = Quality of Architecture =
-* Conceptual Integrity:
+* Conceptual Integrity: is the underlying theme or vision that unifies the design of the system at all levels. e.g. Built for massive scalability where scalability is the underlying theme.
-* Correctness and completeness:
+** Better to leave out features if they are not central to theme.
-* Buildability:
+* Correctness and completeness:

@@ Line 160: / Line 160: @@
 = Business Qualities =
-* Time to market:
+* Time to market: Development time, pressure to buy COTS. Will be easier if system is decomposed into elements.
-* Cost and benefit:
+* Cost and benefit: Architecture that is highly flexible or relies on technology will be more expensive to build.
-* Projected lifetime of the system:
+* Projected lifetime of the system: Long life systems need to have high modifiability, portability, scalability.
-* Targeted market:
+* Targeted market: If mass market, the platforms on which a system runs determine size. Thus, portability is key. Product line approach should be considered.
-* Rollout schedule:
+* Rollout schedule: If product introduced in increments, then flexibility, customizability are key.
-* Integration with legacy systems:
+* Integration with legacy systems: Integrability is important.
 = Quality of Architecture =

← Older revision		Revision as of 19:29, 21 March 2012
Line 157:		Line 157:
	* Reuse within the same system as well as across systems.		* Reuse within the same system as well as across systems.
	* Depends on degree of coupling.		* Depends on degree of coupling.
		+
		+	= Business Qualities =
		+
		+	* Time to market:
		+	* Cost and benefit:
		+	* Projected lifetime of the system:
		+	* Targeted market:
		+	* Rollout schedule:
		+	* Integration with legacy systems:
		+
		+	= Quality of Architecture =
		+
		+	* Conceptual Integrity:
		+	* Correctness and completeness:
		+	* Buildability:

← Older revision		Revision as of 19:19, 21 March 2012
Line 134:		Line 134:

	* Source: Unit developer, Integration/System/client acceptance tester, System user.		* Source: Unit developer, Integration/System/client acceptance tester, System user.
		+	* Stimulus: Completion of Analysis, architecture, design, class, system increment.
		+	* Artifact: Piece of design, piece of code, complete application.
		+	* Environment: At design time, compile time, deployment time.
		+	* Response: Provide access to state values, provides computed values.
		+	* Response Measure: Percent executable statements executed, time to perform tests, Probability of failure if fault exists.

	== Portability ==		== Portability ==

@@ Line 128: / Line 128: @@
 == Testability ==
 === General Scenario ===
 == Portability ==

@@ Line 125: / Line 125: @@
 * Response: Locates place where change can be made, makes modification independently, tests modification, deploys modification.
 * Response Measure: Cost in terms of no. of elements, quality attributes effected, effort, money etc.
 == Portability ==

← Older revision		Revision as of 19:05, 21 March 2012
Line 130:		Line 130:
	* How easily can a system be moved to a different target environment.		* How easily can a system be moved to a different target environment.
	* Usual strategy: decouple provider from user.		* Usual strategy: decouple provider from user.
		+	* However interfaces take time to define and add run-time penalty.
		+	* Who pays ? Current project manager might be reluctant, if benefits are only for future projects.
		+
		+	== Integrability ==
		+
		+	* How easily different parts of the system work together ?
		+	* Common interfaces in terms of data structures and protocols.
		+
		+	== Reusability ==
		+
		+	* Linked to portability and integrability.
		+	* Reuse within the same system as well as across systems.
		+	* Depends on degree of coupling.