1. SandcastleDesign Proposal 1.7ACDM Architecture ToolAhn, Cho, Chotemateepirom, Haider, Zgraggen10/10/2008Revision HistoryDateVersionAuthorDescription11/24/2008N/ASoo-Yung ChoFirst draft 12/02/2008N/ASoo-Yung ChoSecond draft12/10/2008N/ASoo-Yung ChoFinal draft2/15/2009N/AJaffer HaiderAdded process script for ACDM stages 3 to 6. 3/4/2009N/AJaffer HaiderAdded additional details in the analysis section for detailed design.3/14/20091.1Jaffer HaiderAdded feedback from postmortem meeting.3/20/20091.2Jaffer HaiderAdded changes based on the feedback during the postmortem meeting.3/22/20091.3Jaffer HaiderMade changes based on feedback on previous changes.3/27/20091.4Soo-Yung ChoAdded initial version of detail design approach.3/28/20091.5Soo-Yung ChoTeam review process is added in the detail design approach section.4/18/20091.6Soo-Yung ChoTeam comments are added after review meeting.05/26/20091.7Soo-YungDetail design process is updated after the discussion during the status meeting on 05/26/2009. It was reviewed by Guido, and changes are applied.<br />Contents TOC quot;
1-3quot;
2Design Entry Criteria PAGEREF _Toc225355684 43Design Activities PAGEREF _Toc225355685 43.1Architecture Design PAGEREF _Toc225355686 43.1.1Process PAGEREF _Toc225355687 43.1.2Details PAGEREF _Toc225355688 43.1.3Analysis PAGEREF _Toc225355689 73.2User Interface Specification PAGEREF _Toc225355690 73.3Third Party Libraries Identification PAGEREF _Toc225355691 83.4Detailed Design PAGEREF _Toc225355692 83.4.1Process PAGEREF _Toc225355693 83.4.2Approach PAGEREF _Toc225355694 83.4.3Analysis PAGEREF _Toc225355695 84Design Exit Criteria PAGEREF _Toc225355696 85Changing the Design Proposal PAGEREF _Toc225355697 9<br />Design Entry Criteria<br />Here are the things that we must have before processing design activities:<br />Architectural Drivers Specification<br />Statement of Work (SOW)<br />Design Activities<br />Architecture Design<br />Process<br />For the architecture design process we will be using ACDM process. The stage 1 and 2 are done in the problems definition to define the architectural drivers. To design the architecture of the project, we will follow the stages 3 through 6.<br />Figure SEQ Figure ARABIC 1 ACDM Design Stages<br />Details<br />The following script outlines the process for creating and refining the software architecture of the system. This script has been distilled from the processes outlined in [Lat08]. The script itself is not linear; activities will be performed in a circular fashion, going from ACDM stage 3 to 6 in a cycle until the cycle is exited in stage 5, as shown in Figure 1 above. The script being linear does not however prevent the team from performing activities in multiple stages at the same time. For example, experiments might continue to be performed while the architecture is being refined (stages 3 and 6 will be executing at the same time). It will be up to the team to judge and decide when to enter a stage taking into account factors such as the schedule.<br />ActivitiesDescriptionACDM Stage 3 – create initial design or refine the existing design (in nth cycle)Reference Chapter 10 [Lat08]Planning MeetingThe following activities need to be planned in this meeting (pg 242 Lat08):Update the schedule to add all these activities.Initial notional architecture specification or refining the architecture specification (based on progress in ACDM cycles).Individual architecture specification inspections.Issue analysis by the Chief Architect.Review and issue analysis meeting.Participating roles:Managing Engineer & Chief ArchitectNotional ArchitectureThe chief architect creates the context diagram and the notional architecture of the system. The architecture must be documented in a complete manner.The following tasks should be kept in mind when creating and refining the architecture and documenting it:Establish context.Partition the system based on context.Assign elements and relationships responsibilities. See section 1.2 Templates of the “Software Architecture Documentation” file in /studio/artifacts/architecture in the Subversion repository.Document decomposition rationale.Trace architectural drivers to elements and relationships.Switch perspectives when necessary.Participating roles:Chief ArchitectRefine ArchitectureIf the team has already reviewed the notional architecture and the chief architect feels that they have enough information to proceed refining the architecture, then this activity is performed. The architect uses the artifacts created in stage 6 and any other information to refine the architecture. Note that after the team has a notional architecture, the team will perform this activity (refine) in stage 3, rather than creating a new notional architecture.Participating roles:Chief ArchitectKey Artifact(s) of Stage 3: Architecture design documentationACDM Stage 4 – Review design (only identify issues, not fix them)Reference Chapter 11 [Lat08]Individual architecture specification inspectionsAll team members must evaluate the architectural design individually before the review meeting. All aspects (text quality, correctness of diagrams, and design decisions) of the architecture need to be examined. While evaluating the design, the architectural drivers specification document must be used as a reference.In addition to evaluating the design, members must also familiarize themselves with the requirements documented in the architectural drivers specification document, in order to be better prepared for the review meeting.All issues should be sent to the Chief Architect before the review and issue analysis meeting (next stage), who will compile them into one document before the meeting.Participating roles:Entire teamKey Artifact(s) of Stage 4: Architecture Specification annotated with issuesACDM Stage 5 – Production Go/No-Go DecisionReference Chapter 12 [Lat08]Issue analysis (by Chief Architect)The chief architect goes over the list of issues and works on proposed solutions for issues. These will be discussed in the review and issue analysis meeting.Review and Issue Analysis meetingThe following roles will be defined for this meeting:Moderator (Managing Engineer)Architecture Presenter (Chief Architect)ScribeTimekeeperThe following activities will be performed in this meeting:Quick review of architectural drivers, to refresh everyone’s memory and so that everyone is on the same page.Architecture Overview presentation; the chief architect will describe the architecture in detail. (see Table 11.6, pg 279 Lat08 for presentation structure tips) Questions should not be asked during this section. Any questions should be noted down and kept for later sections of this meeting.Functional analysisStructural analysisThe team goes over the issue list from stage 4 and decides on what action(s) to take for important issues in the Issue Decomposition document. (see Table 12.3, pg 311 Lat08 for issue decomposition template) Based on the decomposition of issues and their actions, the team takes the Go/No-Go decision in this meeting. The Go/No-Go decision should be after these activities have been performed:Analyze all issues.Discuss impact of unaddressed issues or new issues that arise.Evaluate and consider the architectural document if this is ready for detail design.The team will make the decision by consensus (based on the points above). The client will then be involved in the discussion and the Go decision will be taken if the client approves the design.If the Go decision is not taken, the team goes into stage 6 and stage3 (at the same time) if required. If the Go decision is taken, then the team proceeds with detailed design.Participating roles:Entire teamKey Artifact(s) of Stage 5: Issue Decomposition documentACDM Stage 6 – ExperimentationReference Chapter 13 [Lat08]Planning MeetingThe following activities needs to be planned in this meeting:Update the schedule to add all these activities.ExperimentationExperimentation review meetingParticipating roles:Managing Engineer & Chief ScientistExperimentationExperiments identified in the issue decomposition document are planned and assigned to engineers. Engineers perform these experiments and record their results.Currently the results of the experiments are being maintained on the team website. They will be later moved to the experiment planning repository (located at /studio/experiments/ in the Subversion repository) (Table 13.4, pg 322 Lat08)The exit criteria for experiments is identified and agreed upon beforehand. Experimentation review meetingThe results of experiments are discussed with the chief architect or possibly the entire team (it is up to the Chief Scientist). The goal of this is to aid the team in knowledge transfer and technology learning.The team then goes into stage 3 (if stage 3 activities are not already being performed), where the architecture design is refined.Participating roles:Entire teamKey Artifact(s) of Stage 6: Experiment Planning Repository<br />Analysis<br />Process<br />How many times iteration took before getting “Go” decision in the stage 5?<br />How many times the architecture need to be changed after “Go” decision?<br />Architecture<br />Are all architectural drivers are assigned to the architecture?<br />Do we have enough information on each element (and relationship) in the architecture to be able to use it for detailed design?<br />User Interface Specification<br />The Requirements Engineer is responsible for taking the lead in this activity.<br />There will be two types of user interface specification as listed below:<br />Build on paper prototypes<br />Digital diagrams created by Visual C#<br />We will add more detailed to the paper prototypes that were used for requirements and define specification on them. Then, more detailed and realistic version of specification will be created by using Visio’s Windows XP Palette.<br />Tasks in this activity will include (at a high level):<br />Create UI prototype.<br />Discuss UI prototype with the team.<br />Discuss UI Prototype with the client.<br />Validate the requirements with the UI prototype, i.e. the screens conform to the requirements in the architectural drivers specification.<br />These activities will be performed in an iterative fashion, based on the judgment of the Requirements Engineer. To successfully complete this activity, the UI specification must be approved by the rest of the team and the client. All requirements (use cases) must be mapped to screens as well, and it should be discussed with the team whether the screens are actually implementable. <br />Third Party Libraries Identification<br />We must identify third party libraries that we will be using during the implementation phase. T-checks will be used to identify a set of libraries to use. More details are available on http://sites.google.com/site/sandcastlemse/work/rcp-knowledgebase/rmt-graphical-library. <br />Detailed Design<br />After we have a final version of the architecture design, we will begin with the detail design. In this section, rules and a process about creating detail designs are described.<br />General rules<br />The detail design will be individual tasks, but all of the design results will be merged in one document. Each team member will be responsible for detail designs of modules from the architecture. And, the team will be responsible for inspecting individual works. The approach listed below will be performed while the team is going through the TSP IMP script, which is defined in Table 8.1 and 8.2 in [Wat00].<br />The team will follow TSP during the development. The approaches listed below define detailed ways of creating and reviewing detail designs. The approaches support TSP IMP script in a way to define detail designs that would be more helpful for our project.<br />Before starting Individual detail design process, the development manager will be responsible for identifying low-couple modules or parts of the system and assigning them to team members. This activity will be performed during the activity 3 in the TSP IMP script. Individual detail design process will be used in the activity 4 and Team review process will be used in the activity 7.<br />Approach<br />The following table defines TSP steps and activities that are related to creating detailed design. Individual detailed design process and Team review process are defined in sub-sections (3.4.2.1 and 3.4.2.2).<br />TSP StepsDetailed design activityDefined processImplementationThe engineer produce the detailed designIndividual detail design process (3.4.2.1)The team reviews detailed design created by the engineer.Team review process (3.4.2.2)<br />Individual detail design process<br />Each team member who will create detail design must follow the process defined below:<br />Pre-condition:<br />A team member has received module information from the development manager.<br />A team member must have following documents for references:<br />Architectural Drivers Specification<br />Architecture Specification<br />UI Specification (Only for modules of UI screens)<br />Activities:<br />List all use cases that are related to the module.<br />Define all the public interfaces by the module.<br />Write JavaDoc for the public methods defined in the previous step.<br />Define packages and class structures by using the public interfaces. This information will be captured as class and package diagrams in UML 2.0 format.<br />The state machine diagram should be used if necessary. The designer must define precondition states for interfaces/services if the state machine diagram is used.<br />If the module has defined protocol or specific orders of interaction inside the module, this information must be captured in the sequence diagram in UML.<br />Notify to the development manager and review the design together to see if all responsibilities are met.<br />Post-condition:<br />The development manager approves the design.<br />Documentation of complete design.<br />List of public interfaces.<br />JavaDoc for the public interfaces.<br />UML class diagram (only public methods will be defined)<br />UML package diagram (if necessary)<br />UML state machine diagram (if necessary)<br />UML sequence diagram (if necessary)<br />Defects found from the design review are logged in LOGD form.<br />Team review process<br />After the team member creates detail design by team member, it must be reviewed with the team. This approach corresponds to activity 7 in TSP IMP script (pg. 152).<br />Pre-condition:<br />A designer has the first version of detail design approved from the development manager.<br />A designer has documented the design into a document file. The document must have:<br />List of public interfaces.<br />JavaDoc for the public interfaces.<br />UML class diagrams.<br />Activities:<br />The designer sends the design document to all team members.<br />The team members review the design individually and send comments back to the designer.<br />Check if all the interfaces are defined by using the architecture and the architectural drivers specification.<br />Check if all the classes/packages are defined.<br />Check if the module needs other types of diagrams for the implementation.<br />Check if there is enough detail for implementation.<br />The designer gathers the comments into one document.<br />All team members go over the comments together in a meeting , and records open issues and defects in the INS form.<br />The designer update changes to the design.<br />The development manager decides whether the design needs to be inspected again.<br />Post-condition:<br />All the issues are recorded into INS form.<br />The designer has fixed all the issues discovered during the meeting.<br />The development manager updates architecture based on detail design changes.<br />Final individual design is merged into the main detail design document.<br />Analysis<br />Did the design cover all the responsibilities and follow all the constraints that are defined by the architecture?<br />Were there any missing classes or packages found during the implementation?<br />How many issues were injected during the review meeting?<br />Reflection<br />Design Exit Criteria<br />Here are the things that we need to have at the end of design phase:<br />Architectural specification (approved by the client)<br />Experimentation results<br />Design specification (team consensus)<br />User interface specification (approved by the client)<br />Selected third party dependencies (approved by the client)<br />Changing the Design Proposal<br />The processes used by the team can be changed by adding the proposed change to the agenda for the status update meeting. The proposed change will be discussed during a meeting with the entire team until a consensus is reached. This document will be updated to reflect the change.<br />References<br />[Lat08]“Architecting Software Intensive Systems”, Anthony J. Lattanze, 2008<br />[Wat00] “Introduction to the Team Software Process”, Watts S.Humphrey, 2000<br />