czwartek, 28 czerwca 2007

„Evaluating Software Architectures: Methods and Case Studiem” book review

Mood: In hurry

The book describes three methodologies of reviewing system architectures:
ATAM – Architecture Tradeoff Analysis Method
SAAM – Software Architecture Analysis Method
ARID – Active Reviews for Intermediate Designs
It concentrates mainly on the first method and afterwards it describes the following two much more briefly (especially ARID) basing on previous material.

Content of book
The biggest advantage of the book is a very practical approach to the very abstract topic. It is a direct guide for a novice person showing step-by-step how to:

  • prepare for evaluation
  • make evaluation
  • collect feedback from architecture review process

It includes the detail break down of the methods into phases and stages including the suggestions about audience, meeting agenda, topics to cover and threads including the ways of managing them. The authors of the book show a lot of real samples from particular stages of the process and provide number of very useful tips.

Mentioned methodologies do not cover the 360-degree review of the software architecture in particular project, but they concentrate on defining the main bottlenecks of the projects and following deliverables:

  • Creating the usage attributes tree [drawing 3.4, page 72] with assigning priorities to them - ATAM
  • Defining the most critical, common usage scenarios - ATAM, SAAM, ARID
    Creating the real risks list - ATAM
  • Defining quality attributes [drawings 5.1-5.3, page 132; table 6.3, page 190] and quality targets - ATAM
  • Synchronizing the knowledge about project and project vision among key persons in project - ATAM, SAAM, ARID
  • Reviewing available project documentation and architecture - ATAM, SAAM, ARID

Chapter 9 and Table 9.1 [page 274] contains the detail comparison of all three methodologies.

ATAM methodology is the precisely structured (into phases and stages) extension of SAAM method and it is the best fit for:

  • Review of existing project before creating its new version or reuse in other project
  • Formal review by external authority of started or existing software project (for example before taking some strategic decisions)
  • Taking over the on-going or existing project from one team to the other
  • ATAM focuses on big and medium software projects. Tables 2.1 and 2.2 [page 61] show the approximate cost of evaluation process (medium – 36 man days, small – 15 man days).

SAAM methodology [Drawing 7.1, page 234] is more flexible approach to topics covered by ATAM. It is also applicable to big and medium projects, which are during realization or before creating the new version. The main difference between SAAM and ATAM are:
SAAM is focused mainly on functionality and extensibility of the project (ATAM covers wider set of attributes - also security, scalability and reliability)
Slightly smaller cost of the evaluation (minimum 2 days comparing to 3 days for ATAM)
More iterative way of creating the deliverables – agenda of meetings is the same each day and cover topics from all the stages, unlike ATAM, where each stage has different agenda

ARID is the only methodology mentioned, which is applicable during (and not after) the analysis phase. Like SAAM it is based on iterative approach, where agenda (for phase 2) is the same through the whole time of the evaluation process. Unfortunately, this methodology described in a very brief way, without a sample.

The cost of using this methodology is similar to SAAM (minimum 2 mandays).

The common point of described methodologies is the active approach to the review process (Active Design Reviews, ADR) and bringing back the real effects from the process. The main reason of doing it is to guide the evaluation process so it does not provide just junky type of reports “everything-goes-fine;don’t-worry”. The genesis for this approach is the article “Active Design Reviews: Principles and Practises” written by David Parnas and David Weiss described in details on page 261. It says among others about proper way of putting the questions (non-rhetorical, but focused on descriptive answer), what brings back much better answers and results from review process.

Other methodologies
The book mentions also the number of the other evaluations methodologies (in Chapter 9) like:

  • Quality Attribute Workshop (page 286)
  • Software Performance Engineering (SPE)
  • Survivable Network Analysis (SNA)

They are not described in details and book is just a good reference point for further readings about them.

Source of Document Templates
Book provides also number of good template for number of documents like usage scenarios, usage scenario analysis [table 6.4, page 196], architecture approach [drawing 3.6, page 81], quality attributes, architecture drawings etc.

It seems like authors of the book WANTED to create the full review of all “architecture review” approaches and they started it, with the full and a very nice ATAM overview, but afterwards it seems like they did not have enough steam to do the same for the other methodologies doing shorter and shorter descriptions in following chapters. At the end of the road, instead of a nice encyclopedia type of the book, it is in fact the book about ATAM and similar methodologies. It concentrates just on a middle and big projects, which already has started and does not give a lot of support for analysis phase (except short description ARID), where the most of this type of work SHOULD be done. Unfortunately, it seems like the reason of such approach is quite simple – the authors are selling their service and support in ATAM area.

There is number of references to other methodologies, but there is a visible lack of connection to software designing approaches like Agile methodologies, RUP, MSF or project management methodologies like Prince2 or PMBoK. Such two chapters would show much better where these processes could be applied during software development process.

Despite of the criticism, the book is definitely worth of reading as it is VERY practical and it shows a unique point of view for project managers, software architects, stakeholders and other key players in software development process. It provides a VERY good starting point for preparing the evaluation process, giving a number of nice tips; among others it says how to convince the stakeholders that the whole evaluation process is necessary and how to build the review architects team.

Final score: 4 (good)/6

References to pages may be slightly different in English version of the book as the article bases on polish translation of the book made by Helion.

niedziela, 24 czerwca 2007

Here it goes - Right here! Right now!

Mood: Hang-over relaxation
Soundtrack: Right here! Right now! FatboySlim

Blog or not to blog
For a long time I doubt in the whole blogging *thing*. In fact Blog is nothing more than just eDiary and I did not want to be the kind of Adrian Mole folk! What has convinced me to write these words? Tomasz Kopacz, Joel Spolsky and Michael Ekegren. Work of these guys is for me the definion of techblog, which is a great way to exchange knowledge. There are guys, who are willing to share and this is why the world is turning around. As word "blog" seems not to be the next buzz-word I have decided to jump in on that train.

Which blog engine?
Willing to make a change I thought that everything else will be easy, but... Here it goes. Damn internet freedom of speach caused that there is the infinitive number of variants how the thing can be done. The best start point for the discussion seems to be Newbie FAQ 101 - How to make a blog. Typepad means paying > out. LiveJournal... well, I am quite sure that somewhere there is Adrian Mole. The cool thing there though is the mood parameter, which can be assigned to each post. The last one mentioned blog engine is Blogger. After reading just the article it would be obvious but... there is also ITTollbox. The design of the page is quite rickety and too-precisely-organized (limiting freedoom of expression), but the content of the service is good. There is unfortuntally common set of functionalities between this and my favourite LinkedIn (why the hell they have answers&questions and they have no blogs!!!).
I will try to live somehow with duplicated accounts in these services.

TechBlog manifesto

1. I do spend 1,2 hours weekly (mostly during the weekend) on writing (if I have no clue what to write about I will pick up some question from linked in)

2. I do write about:
  • project management
  • software development
  • web 2.0 (including some interesting services on the web)
  • time organization
  • book reviews
  • other interesting (in my opinion) technical things
3. I do not write about non-technical things (despite there is Mr. Heyd who wants to write some other stories, but if he starts to speak loudly, he will speak on the other blog)

4. I will write in english, but from polish perspective (I hope this will make the techblog unique)

5. No cross-words (however borders are not established yet) and no bull shitting.

6. I do post some info packs with links to posts in other blogs, but I will always write at least one sentence about each

7. I do write the techblog for people, so I will answer your comments and I will be opened for suggestions of type "please, write about..."

8. I will respect each opinion from the others, even the one which is totally opposite to mine and any of the criticism will not be taken personally (assume I can count on the same on the second side). If there is anything what seems to be stupid (even gramma), please write the comment.

9. There will be some humour in the blog (I hope it will not be just about that :D)... and at least 3 smilling faces. :D :D

10. There is no rules at the world, so each rule above can be broken under special cirumstances - author is obligated however to explain why the rule is broken. The sample:
*s..t* (sorry for braking the rule 5, but this guy just .... my head off and ... mother.... and I will ..... ) - I truely hope these words will not be written about you as I am very polite and opened kind of person, but as Leo Beenhakker said "a lot of stupid people walk on the Earth"

Good bless Google again! Amen, period and publish.
web metrics