Using Agile Techniques design a Personal Environment Network

Posted on by

Project:
Using Agile Techniques design a Personal Environment Network. Identify and classify which components need addressing and how, using Agile development, this will be achieved.
The outcome of this project will a document or documents addressing these components
1) Communication
2) Planning
3) Modeling
4) Construction
5) Deployment.

Organization and Flow:
• Project planning
• Use case development
• Requirement gathering
• Rapid design
• Code generation
• Testing

1. Requirements
Introduction and Project overview
• Problem
• Purpose
• Scope
• Stakeholders
• Product Perspectives
• Project Functions
• Limitations and Risks

Scenario-Based Elements
• Use-Cases Text
• Use-Cases diagrams
• Swimlane Diagrams
• Sequence Diagrams

Behavioral Elements
• State-Diagrams
• Activity Diagrams

Class-Based Elements
• Class Diagrams
• CRC Models
• Collaboration Diagrams

Interface Elements
• Use Cases
• Swimlane Diagrams
2. Architecture
• Processing Narratives
• Design class realizations
• Subsystems
• Collaboration Diagrams
• Data Structures and algorithms
• Formal Methods
3. Design

Refinements to: (further detail from requirements)
• Design Class Realizations
• Subsystems
• Collaboration diagrams
• Activity Diagrams
• Sequence Diagrams

Technical Interface
• Sensor Interface Overview
• Sensor Data Format

Navigation Design GUI
GUI Design
• Sequence Diagram
• State Diagram

4. Testing
For Each Class
Description of a Test For:
• Interface
• Local data Structures
• Boundary Conditions
• Independent paths
• Error-Handling paths
Overview:
A personal Environment Network is a network of ad-hoc device (cell phones or other WIFI wireless devices) that organize themselves into an active network to exchange information that is determined by each individual device.

The application that allows the information exchange is responsible for security, look and feel and protocol. The underlining communication protocol is also part of the application. Furthermore, the application is capable of routing thru a node to get a link to a node outside a original nodes transmission range.

These devices do not need any cell tower requirements, although it is possible.

According to Wikipedia these devices follow this definition: A mobile ad hoc network (MANET), is a self-configuring infrastructure-less network of mobile devices connected by wireless links. ad hoc is Latin and means “for this purpose”.

Each device in a MANET is free to move independently in any direction and will therefore change its links to other devices frequently. Each must forward traffic unrelated to its own use, and therefore be a router. The primary challenge in building a MANET is equipping each device to continuously maintain the information required to properly route traffic. Such networks may operate by themselves or may be connected to the larger Internet. MANETs are a kind of wireless ad hoc networks that usually has a routable networking environment on top of a Link Layer ad hoc network.

The growth of laptops and 802.11/Wi-Fi wireless networking have made MANETs a popular research topic since the mid-1990s. Many academic papers evaluate protocols and their abilities, assuming varying degrees of Mobility within a bounded space, usually with all nodes within a few hops of each other.

Different protocols are then evaluated based on measure such as the packet drop rate, the overhead introduced by the routing protocol, end-to-end packet delays, network throughput etc.

Use case:

The user of the device sets their device to accept information from:
• Friends
• Ads by category
• Classmates
• Device specifications in stores
• Home appliance devices

Classification of some simple use cases:
1) Item identification and location
2) ad-hoc social networking
3) ad-hoc phone services (vs. cellular phone service)

This is a basic guide for the components of the project (requirements, architecture, components, user interface and testing)

Requirements:
1. Start with task set, page 24
2. Review the process steps on page 71
3. Review core principles 6.1.1 and 6.1.2
4. Review your 2 use case examples against list on page 115 (mid page)
5. Use INFO on page 106 to guide requirements, (validation)
6. Read appendix 1, page 611
7. create high-level use case diagram, example on page 119, figure 7.2
8. create either an activity diagram (page 151-154) or a swimlane diagram (page 153-154) of the use case
9. next move on to chapter 8
10. read 8.3.1 (identifying classes)
11. create a list of items for your system that look like the table at the top of page 137 (fig 8.2)
12. Read 8.3.2 (specifying attributes)
13. create a list of items for your system that looks like figure 8.3
14. read 8.3.2 (Defining operations)
15. create a class diagram of your classes (each one) figure 8.4
16. if is very helpful if you use CRC cards (figure 8.5) and finally read 139 carefully
17. address multiplicity and dependencies, page 614

Architecture:
1. Read 10.1 (all of it)
2. Review figure 10.7 (create your system using this model), you can also use (figure 10.8.10.9 or 10.10)
3. Read 10.7 evaluate it against your system
4. Finish up architecture with 10.7.3

Design:
1. Start with chapter 11
2. Create your system using the layout in figure 11.1
3. Further define your system using figure 11.3
4. read all of 11.2 (all of it)
5. now review figure 11.6 and 11.7
6. Review figure 9.4 to validate design vs requirement
7. now use the architecture decision description template on page 185 as a guide
8. fill in this list for each problem defined in your use case (your functional items)
9. your architecture will be either layered or object oriented (page 189) figure 10.3 so your diagrams will be with figure 10.4 or figure 10.5 (class based)
10. now create a architectural context diagram (page 197 figure 10.3)
11. then create a overall architectural structure diagram (figure 10.9)
12. now components (chapter 11 – remember components give a more global definition)
13. if your system is class based (which it is) read 11.2 use the figure on page 11.4 to identify OCP (sensors, system and user interface) do one for each (and for both use cases)
14. if you went the route of component level the read 11.1 then create a diagram such as 11.1

User interface: (chapter 12) (also read chapter 13 on mobility)
1. read 12.1 (all of it)
2. review the info on page 236 (use the list mid page as a guide)
3. review 12.3 interface analysis
4. Review the golden rules 12.2
5. use 12.3 figure and 12.1.3 as guidelines of what should be considered layout a screen for the PEN (figure 15.3)
6. sequence it with figure 12.2

Testing:
1. Read chapter 19 and 20
2. review the figure 19.3 (this will be your guideline)
3. create a Unit test (figure 19.4) for each component (and or class)
4. read 19.4.1 on page 384
5. review the figure 19.5 to help address testing concerns
6. Read 19.6 for OO testing
7. Review 20.2
8. Use figure 20.2 and 20.1 (either on can be used)
9. then address interclass testing (figure 20.3)