SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 T Software Architectures Introduction to Exercise Spring 2008

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Exercise  Idea  To address central architectural issues in the form of group discussions around a case product  All groups work on the same case individually ➔ you are not expected to produce the same architecture design!  It is important to justify your decisions and retain the consistency in your design documentation  Group works on architectural issues of the case  Why’s are important!  Details will show up on course web pages  They will be updated regularly  Check before the each phase, as we try to take any feedback into account and adjust accordingly

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Exercise phases (Deadlines are strict!) :00Stakeholders, concerns, and views :00Message from the board :00Design :00Peer review 21. – Evaluation sessions :00Final design You may want not to leave this to the last minute!

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Group meetings  Main work of the exercise should happen in group meetings  Either physical or virtual  Discuss your design and deliverables  Make notes on the meetings  These will be returned as part of the exercise deliverables  The typical scheme of splitting the work into three individual parts and then integrating work a couple of hours before DL will not lead into good results

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Exercise setting  Company X is investigating the feasibility of building a system for detecting forest fires  The job of your team is to sketch the overall architecture and consider the most critical architectural concerns in more detail.  You only have very limited time, i.e., a bit over month from the first ideas to come up with the initial architecture draft.  The draft you will produce will be evaluated by a group of stakeholders, and the design will be revisited  Based on the final results, the final go/no-go decision regarding the production will be made

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Topic  Each group will target the same topic  A system to predict forest fires  An overall description of the case as well as a list of requirements for the system are given  The list of requirements acts only as a starting point  Many requirements are not measurable as such  Some requirements may be missing  Some requirements are not that important  Your task is to explore, expand, prioritise and concretise  Within the topic, aim for depth rather than width

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Phase 1: Stakeholders, concerns, and views  Identify architecturally significant stakeholders  Identify architecturally significant concerns; either functional or non-functional ones  Explicate assumptions and constraints  Concretise the most important architecturally significant concerns as scenarios  Identify views and viewpoints that are needed to design a system that fulfills abovementioned concerns  The returned document acts as a template for your architecture design document  Used as a basis for phases 2 and 5

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Message from the company board  After the first phase, each group may receive a message from the company board  For example, the company board may express its worry that particular concerns may be difficult to achieve  Before starting the second phase, the group must refine the results of the first phase by redefining and re-prioritising their concerns  The goal of the group is to take the message from the company board into account in their design

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Phase 2: Design  Design your architecture  Context diagram  Main structural view  Deployment / distribution view (optional)  1-2 views to address the most important architectural concerns  The material you produce should enable the review of your architecture design.  The reviewer should be able to see  That your concerns are of importance  That your choice of views is meaningful  That your views describe how the concerns are addressed (that is, reflect the design decisions that implement major architectural requirements)

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Phase 3: Peer review  Each group is allocated the architecture documentation of two other teams  Your task is to review their work thus far and give them guidance for future work  Write the review as a document  A checklist is available for this purpose

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Phase 4: Evaluation session  Select one method that uses scenarios for evaluation, and apply it to your design  Evaluate the fulfillment of the major architectural concerns  Present your design as well as results of the evaluation in a session  Each session will be participated by approximately three groups  Oppose the evaluation of other groups within your evaluation session  Details on how to reserve a time for your group session will be published later

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Phase 5: Final design  Based on the comments from  Peer reviews  Results of the evaluation  Feedback from the course staff  finalise your design document.

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 Grading  Grading from 0 to 40 points  20 points = passed  Grading is based on  Returned documents  Peer review  Presentation in the evaluation session  Opposing in the evaluation session

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Tomi Männistö, Varvana Myllärniemi, 2008 To get things started  Read exercise information from the course web pages  Discuss, think what is important  In real life, customer requirements, business case etc. information may often be inexistent, incomplete, incorrect and contradictory  There may not be a clearly defined problem to which seek a solution  It is more about understanding what are the aims and make suggestions and decisions towards them  Agree on dates for group meetings