Presentation is loading. Please wait.

Presentation is loading. Please wait.

PDD Development Questions

Similar presentations


Presentation on theme: "PDD Development Questions"— Presentation transcript:

1 PDD Development Questions
TLEN 5700 Research Methods Lecture 7 ITP Candidate Capstone Projects PDD Development Questions Kevin Gifford October 11, 2017

2 Capstone Project Milestones Draft PDD to Instructor
Sep 2017 Oct 2017 Nov 2017 Dec 2017 Topic Presentations Wed. Sep 13 Teams & advisors set Wed. Sep 27 Draft PDD to Advisor Friday, Oct Draft PDD to Instructor Fri. Oct PDD Wed. Oct CDD Wed. Nov 1 PDR Wed. Nov 15 CDR Mon/Wed Dec 11, 13 PDD: 1st draft to advisor; 2nd draft to Instructor; Final draft to instructor PDD must be signed by the customer (represents common understanding and goals)

3 Project Definition Document

4 Engineering Design (Applied Research) Definition
Engineering Design Process steps Define the Problem Do Background Research Specify Requirements Brainstorm Solutions Choose the Best Solution Develop Prototype Test and Redesign

5 Project Definition and Customer Interaction
Who precisely is the customer? Who is the academic advisor? Who is the industry advisor? What is the problem or need? What are the projected/anticipated benefits? What are the customer requirements for the system or product? Can any constraints be identified? What previous work has been done in this area? Previous work: literature searches, business and engineering libraries, trade journals, professional society publications (e.g., IEEE, ACM, etc.), industry experts for inputs and guidance, web searches (e.g., ask Google), online tutorials… What are the (“my”, “our”) project requirements?

6 Project Definition: Organizational Strategy
Questions Requirements & Constraints Design Drivers Strategies for Success Organizational Functional Administrative Engineering Design Budgetary Related Products References Objectives and/or Levels of Success Questions Hardware Software

7 Capstone Project Milestones: Requirements Generation
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include: Requirements inception or requirements elicitation - Developers and stakeholders meet, the latter are inquired concerning their needs and wants regarding the software product. Requirements analysis and negotiation - Requirements are identified (including new ones if the development is iterative) and conflicts with stakeholders are solved Requirements specification - Requirements are documented in a formal artifact called Requirements Specification (RS). Suggestion: Carry the requirements, and any design drivers, in an Annex Requirements validation - Checking that the documented requirements and models are consistent and meet the needs of the stakeholder.

8 Project Definition: Customer Stated Project Goal (NASA slant)
This project will provide (1) a Space Wireless Communications Testbed for support of NASA wireless network communication research activities; and (2) Identify programmatic next steps and future research activities to best support NASA Explorations and Operations Missions. The long-term goal is to set up a comprehensive Proximity Wireless Communications testbed facility with broad RF design, modeling, prototyping, and testing capabilities. The ExWC Testbed must support automated configuration and build the required software management infrastructure to enable rapid deployment, set-up and ASAP field operations for wireless network communications systems The required Data Center support infrastructure must be built in a completely automated fashion (e.g., build system). The required wireless network configuration and administrative services must be able automatically built and must include an automated validation functionality that verifies proper network configuration and expected operations.

9 Related information: LTE Cell Tower (Fixed eNB)

10 Related information: Deployable System & Compact System

11 Related information: 4G/LTE Architecture Overview
While only 2 eNodeBs are shown, in practice there are multiple eNodeBs and multiple instances of the EPC elements; and there are many-to-many links between eNodeBs and MMEs, between MMEs and SGWs, and between SGWs and PGWs. Mobility Management Entity (MME) Supports user equipment context, identity, authentication, and authorization Serving Gateway (SGW) Receives and sends packets between the eNodeB and the core network Packet Data Network Gateway (PGW) Connects the EPC with external networks Home Subscriber Server (HSS) Database of user-related and subscriber-related information Interfaces S1 interface between the E-UTRAN and the EPC For both control purposes and for user plane data traffic X2 interface for eNodeBs to interact with each other Again for both control purposes and for user plane data traffic

12 Related information: Background on vendors, industry
Nokia, Ericsson: LTE System Hardware and Software (and 3rd party associates) Who are the four big U.S. carriers? Who are the big carriers in India, EU? Let’s chat about vendor market strategies… Who are the major EPC players?

13 Testbed #2 Boulder Testbed Fixed site radio head (eNB)
Deployable System: Mobile (eNB) and optional core vEPC Data Center software core vEPC Boulder Testbed Fixed site radio head (eNB) Deployable System: Mobile (eNB) and optional core vEPC Data Center software core vEPC

14 Example: Baseline Test Bed Architecture
Network 1 - Fixed Network 2 - Mobile

15 Requirements & Constraints
The ExWC Testbed shall support automated configuration and build the required software management infrastructure to enable rapid deployment, set-up and ASAP field operations for wireless network communications systems The required Data Center support infrastructure must be built in a completely automated fashion. The required wireless network configuration and administrative services must be able automatically built and must include an automated validation functionality that verifies proper network configuration and expected operations. The system shall demonstrate operations with at least one fixed eNB and one Deployable System: network topology scenarios (resiliency) The system shall be able to support flexible core hosting at the Data Center and/or with the deployable system (resiliency, redundancy) The system shall be able to replicate virtual cores on-demand in an automated, containerized manner via orchestrated SDN/NFV build (replicability, reliability) The system shall be able to easily, in an automated fashion, replicate the entire system for a remotely located testbed facility. [Strategy] Build testbed infrastructure in phased manner [Strategy or Requirement?] Need a modern fixed eNB; keep vEPC up to date

16 Requirements & Constraints
Any questions right now – remember your questions will most likely be of value to your peers as well. Make appointments with the instructor if need assistance in this regard. Your academic advisors should be able to assist.

17 Design Drivers Design Driver #1: We are testing the standard and must be vendor agnostic to both hardware (radio) and softwarization (Network Core) Design Driver #2: Must have Upgrade Path for evolving network core “virtual EPC” (Evolved Packet Core, vEPC) Design Driver #3: Must be able to replicate the software cores with no licensing cost impacts

18 Back-up Slides

19 Use Cases (engineering) and User Stories (agile methodologies)
A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user storydescribes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. _______________________________________________________________________ In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. The actor can be a human or other external system. Planning Notes 11-Mar-2013: Discuss SABL Project Plan with Shea and Louis Coordinate dates for RSA 2FA TIM at HOSC (Shea, Jim, Shankini); cost share this trip with BioServe Determine timeline on DTN2 Simulator – coordinate HOSC DTN2 G/W testing, test plan, with the HOSC Will need to plan Automation support for additional BioServe SABL tasks Have an IDSCam close-out sprint; can transition to SABL early as necessary HOSC RSA 2FA meeting this week and travel coordination

20 Capstone Project Milestones: Project Definition Document
Project Definition Document (PDD):  The Project Definition Document (PDD) forms the technical foundation for a design project. Its purpose is to clearly define the design problem that will be solved, and to ensure the design team has the requisite resources and capabilities. The design problem definition consists of an articulation of the need being served, specific objectives and levels of success for the design to satisfy this need in the context of the design course, and specific functional requirements the design must provide to satisfy those objectives. Team capabilities and resources are assessed relative to an initial analysis of the critical project elements (“tall poles”) that must be addressed for a successful design solution. This assignment should be approached in the order given, i.e. define the problem and research related work before the specific objectives are identified. The PDD is developed in cooperation with the project customer, and represents a common understanding of the project focus, functional requirements, scope, and deliverables. Customer approval is due at the time of PDD submission. Deviations from the set of objectives provided here will not be permitted without customer and advisor approval in the form of a revised PDD. The Projects Advisory Board (PAB) will review the PDD for clarity of purpose and credibility of the critical project elements, together with the corresponding team capabilities and resources. The PAB will issue a judgment of “acceptable” or “not acceptable” for readiness to begin the conceptual design phase, along with specific feedback on weak PDD components. Only teams with an “acceptable” PDD will be permitted to continue with the design process leading toward the Preliminary Design Review (PDR). Others must revise the PDD until an “acceptable” project definition is obtained.


Download ppt "PDD Development Questions"

Similar presentations


Ads by Google