We all are familiar with the SDLC process and the role reviews play in helping ensure that the final product is of good quality and is able to meet the system requirements. Reviews are of many kinds ranging from code reviews, test plan reviews, design reviews to performance reviews, audit reviews etc. Let us focus for the moment on design reviews. Typically in the software design phase, the design team receives the requirements in the form of the BRD, the FS or whatever name your organization has chosed to call the inputs. They then proceed to model the application using the tools available like Rational Rose, visio etc. The end result is a set of diagrams and maybe some code which is handed over to the development team for coding. One of the important artifacts that the quality team insists on is the traceability matrix which helps them to verify if all the requirements mentioned in the BRD, FS etc have been covered. But how to we ensure coverage throughout the SDLC process. Did the design team cover everything. If they did, then did the development team leave out something. Did the test cases cover every part of the system and was every functionality tested thoroughly. Thus it becomes essential that the coverage report exists for the design and development phases atleast. The traceability matrix is generally used for checking coverage after the development phase and before the release of the product. There is no real template to document the design coverage other than a set of checklists. You might have come across checklists that contain questions like:
1. Have all mandatory diagrams (Use Case, Class, Collaboration, Sequence, Deployment and Component diagrams) been included?
2. Have symbols and notations been used consistently?
3. Have all assumptions and dependencies been explicitly stated? Are these realistic and reasonable?
Use Cases – Every user interaction with the system must be documented as an Use Case and should be supplemented by an Use Case Diagram.
4. Define the use cases for all the possible interactions of actors with the system.
Activity diagrams - It must address all the requirements specified by the use case. (Activity diagram ensure that the data flow is as per the use case.
5. Describe the internal behavior of an operation pictorially
6. Depict activities that can occur in parallel. The discovery of activities that can occur in parallel will help us to build processes that are more efficient.
7. Help to identify activities whose responsibility belongs elsewhere
8. Allow the discovery of common functionality within a system
9. Show the dependencies, which can be easily identified during the behavior change of the system.
10. Define appropriate relationships between classes. Appropriate design patterns should be used while designing the system. The performance parameters should be taken into account during this process.
and so on
But how do we evaluate a design from an architecture perspective. How do we know that the present design would meet the peak maximum load of a 100,000 concurrent users. Would the system use the same resources irrespective of whether there are 50 users or 500 users. Would the system be able to withstand a DoS attack. Would it allow other applications running on the machine access to some resources or hog all the resources itself. How do you answer such questions by looking at a set of diagrams. Well looks like this others have thought of this before and arrived at some mechanisms to solve this problem.
The methodology is called the Software Architecture Analysis method (SAAM) and relies on a scenario based approach to evaluating software architecture against a set of quality attributes. Some of the main quality attributes include scalability, reliability, security, interoperability etc. In an SAAM evaluation, scenarios representing the quality attributes of the system are developed, prioritized,
and analyzed against the architectural approaches chosen for the system. The results of the analysis are then expressed as risks, sensitivity points, and tradeoffs.
After the scenario generation meeting(s), the refined scenarios are converted
into architectural test cases that the architecture team analyzes against the system architecture. This analysis The architectural test case development and analysis often takes place over an extended period of time (perhaps months) before the architecture team presents the results of the analysis to the stakeholders. This way the software architecture/design can be arrived at as a set of metrics that reveal how the architecture/design measures up against a set of quality attributes.
For more details regarding SAAM and software architecure evaluation can be found at
http://www.sei.cmu.edu/architecture/pub_by_topic.html#evaluation
Saturday, October 06, 2007
Thursday, October 04, 2007
Twenty-20に 世界 コ-フお 勝利 した いんと゛の 選手に おめて゛とう こさ゛います
わたしは 来週の さいこ゛に エゲレスへ しゅっちょうに
行きます.
しゅっちょうの し゛かんは に週間く゛らい あるそて゛す
わたしは この 前に エゲレスへ いった ことか゛ ありません
エゲレスは たへん きれいそ て゛す エゲレスは この こ゛ろ たへん さむらし て゛す
そして 冬服は たくさん 持って いかわなけれは゛ なりません. チヤンナイは たへん
あついのて゛ 冬服は 要ないた ます゛ エゲレスの いろいろな ところお
旅行する つもり て゛したか゛て゛も し゛かんか゛ ないから いくのお やめます
この しゅっちょうは エゲレスに ある 有名な 銀行 LTSBの コルフ゜レト ヘ゛ンキンク フルマウレクお (CBF) 分解
するのためて゛す わたしは LTSBの セステマの テクニカル イスヘ゜クトは 分解 します
コル ヘ゛ンキンに ついて 知て いないと この 仕事は て゛きません
わたしは 来週の さいこ゛に エゲレスへ しゅっちょうに
行きます.
しゅっちょうの し゛かんは に週間く゛らい あるそて゛す
わたしは この 前に エゲレスへ いった ことか゛ ありません
エゲレスは たへん きれいそ て゛す エゲレスは この こ゛ろ たへん さむらし て゛す
そして 冬服は たくさん 持って いかわなけれは゛ なりません. チヤンナイは たへん
あついのて゛ 冬服は 要ないた ます゛ エゲレスの いろいろな ところお
旅行する つもり て゛したか゛て゛も し゛かんか゛ ないから いくのお やめます
この しゅっちょうは エゲレスに ある 有名な 銀行 LTSBの コルフ゜レト ヘ゛ンキンク フルマウレクお (CBF) 分解
するのためて゛す わたしは LTSBの セステマの テクニカル イスヘ゜クトは 分解 します
コル ヘ゛ンキンに ついて 知て いないと この 仕事は て゛きません
In a spineless display of courage, the Indian government is silent on the pro-democracy movement in neighbouring Burma. By their silence they have proven that they do not care for human rigts, democracy etc which they themselves claim to uphold so often. They have failed to practice what they preached and have thoroughly let down a neighboring country that desperately needs its help to free itself from a military junta that has ruled dictatorially for over 40 years. Its sad to hear external affairs minister saying that sanctions should be the last resort when national and international expectations are that India would do much more than that. If sanctions are the last resort, then what's the first, invite the leader of the junta for a state dinner with the president. India has by its silence expressed its solidarity with the wrong side of the struggle and not where it should rightly be, with the peace loving people of Myanmar. It is imperative that India stirs out of its lethargy and do its utmost to free the burmese people from the clutches of the dictators and let the burmese people choose the person that they want to lead them. The freeing of activist leader Aug suu kyee would be the first step to take towards achieving that end.
Subscribe to:
Posts (Atom)