ICUCMU MSITSE - PowerPoint PPT Presentation

Title: ICUCMU MSITSE


1
Practicum Project Status Report
Middle of Semester Presentation
ICU-CMU MSIT-SE Chang Sun Song
2
Contents

• Introduction
• Current Status
• Future Works
• Questions

05/05/2005
2005 Spring
2
3
I. Introduction
Middle of Semester Presentation

• Plan
• Background
• Project Objective
• Product Context

05/05/2005
2005 Spring
3
4
1. Overview

• Period
• 2005 Spring Semester 2005 Summer Semesters
• Involvement
• Team Member
• Changsun Song
• Technical Advisor (Customer)
• David Garlan, Sungwon Kang
• Mentor
• Mel Rosso-Llopart
• Goals
• Have an experience of a real system development
• Have deep understanding of architecture and
  Statechart

05/05/2005
2005 Spring
4
5
2. Background

• Behavioral aspects of an architecture
• Runtime View
• Shows only snapshot of the system
• Doesnt show a series of steps that a system will
  take, responding to stimulus.
• So, typically, sequence diagrams are used to
  describe how a component interacts with others,
  but a sequence diagram covers only one scenario.
• Without behavioral specification, its hard to
  analyze behavioral quality attributes
• Functional Correctness
• Performance
• Timing
• Statechart
• Has formal semantics, so it can be used to
  analyze behavioral quality attributes.
• Widely used as a part of UML
• More expressive than a sequence diagram.

05/05/2005
2005 Spring
5
6
3. Project Objective

• Add two functions to AcmeStudio
• Behavioral Specification
• For components and connectors
• Graphical specification, based on Statechart
• Textual specification in XML, based on DTD schema
  that I defined
• Architecture Simulation
• Based on the statechart specification and the
  structure information of the architecture
• To show how an architecture responds to a stimuli
• For example, what happens to a two tier system,
  if Internet is disconnected?

05/05/2005
2005 Spring
6
7
3. Conceptual Context
05/05/2005
2005 Spring
7
8
II. Current Status
Middle of Semester Presentation

• Status Overview
• Requirements Development
• Overall Architecture
• Risk Management
• Lesson Learned

05/05/2005
2005 Spring
8
9
1. Status Overview

• Software Project Management Plan
• Current Version 0.31
• Risk Management Plan
• Quality Assurance Plan
• Configuration Management Plan
• Missing Test Plan
• Will be defined after requirements validation
• Software Requirements Specification
• Current Version 0.9
• Being reviewed by a technical writer
• Architecture Design
• Working on designing high level architectures

05/05/2005
2005 Spring
9
10
2. Requirements Development

• Requirements Elicitation
• Client Meeting once a week
• Research on existing tools and papers
• UI prototyping
• Requirements Analysis
• Requirements Dependency Analysis (Change Impact
  Analysis)
• Requirements Prioritization

05/05/2005
2005 Spring
10
11
2. Requirements Development

• Requirements Dependencies (Impact Analysis)

05/05/2005
2005 Spring
11
12
2. Requirements Development

• Requirements Prioritization

05/05/2005
2005 Spring
12
13
3. Overall Architecture

• Important Non-Functional Requirements
• Extensibility
• When a user wants AcmeSimulator to support more
  Statechart elements, the user is able to extend
  AcmeSimulator by modifying at least components.
• When a user wants to use some set of
  AcmeSimulator functionality for developing other
  system, the user is able to find the relevant
  implementation units and to use them at least
  modification.
• Usability
• When a user wants to change the current
  perspective from AcmeStudio into AcmeSimulator,
  the user can do that without need to open
  additional views that is the way to open a
  perspective in the Eclipse platform.
• Technical Constraints
• Eclipse Plug-in
• The purpose of this project is to add a behavior
  specification and its simulation functionality
  into AcmeStudio, one of eclipse plug-ins.

05/05/2005
2005 Spring
13
14
3. Overall Architecture current version
05/05/2005
2005 Spring
14
15
4. Risk Management
05/05/2005
2005 Spring
15
16
VI. Future Works
05/05/2005
2005 Spring
16
17
IV. Questions

• Without ATAM, how can I guarantee my architecture
  is satisfying quality attributes? Is there any
  other way to do it?
• I need to make prototypes for several
  requirements. How can I effectively reuse the
  prototypes for implementation? Or, in what way
  can I make prototypes so as to be reused, while
  satisfying the original purpose of prototyping?
• I want to implement only with an architecture
  without detail design, because detail design
  seems to take too long time. Is there any problem
  with this approach? If yes, would you recommend a
  way to make up the problems without detail
  design?
• I spent almost one month for mitigating a
  technical risk. My mitigation strategy to study
  on the technical area. Would you recommend an
  effective way to mitigate technical risks?

05/05/2005
2005 Spring
17
18
?
19
Appendix.A Risk Assess Mitigation Plan
05/05/2005
2005 Spring
19
20
Appendix.B Quality Attribute Scenario
05/05/2005
2005 Spring
20
21
Appendix.B Quality Attribute Senario
05/05/2005
2005 Spring
21
22
Appendix.C Requirements
05/05/2005
2005 Spring
22