Software Engineering Background For Questions 1-7: Kean Univ

Software Engineering Background for Question 1-7 : Kean University Is Pl

Kean University is planning on doing away with the parking permits used previously and moving towards a “pay as you go” system employing price elasticity. The system will use RFID sensors on parking spaces, Kiosk systems to purchase tickets, and will determine pricing based on current demand and historical data. Users can pay via credit card or KU Card. Your company has won the contract and you will lead the project. The questions include selecting appropriate process models, requirements listing, designing use cases and diagrams, architectural styles, principles, testing, and software quality concerns.

Paper For Above instruction

In this paper, I will address the comprehensive planning and design considerations for the proposed pay-as-you-go parking system at Kean University. This will include selecting suitable software process models, identifying functional and non-functional requirements, designing use cases and architectural styles, and addressing testing strategies and quality principles.

1. Selection of the Software Process Model

For this project, an Adaptive Software Development (ASD) process model would be appropriate. The ASD model emphasizes flexibility, iterative development, and customer involvement, which are crucial given the evolving nature of the parking system. The requirements involve real-time demand data collection, dynamic pricing algorithms, and integration with payment systems, all of which benefit from incremental development and frequent feedback. Assumptions include the need for frequent updates based on demand data and the possibility of changing system requirements after initial deployment.

Justification for choosing ASD centers on its adaptability to changing requirements, its iterative approach allowing for gradual implementation of features such as RFID sensor integration, kiosk interfaces, and payment processing. Since the project involves complex interactions and real-time data analysis, an iterative process allows the team to manage risk and incorporate stakeholder feedback effectively.

2. Functional Requirements

• RFID sensor system integration: The system must detect if a parking spot is occupied or free (Functional System Requirement).
• Pricing determination: The kiosk must calculate parking fees based on current and historical demand data (Functional System Requirement).
• User payment processing: Users can pay for parking using credit cards or KU Cards at kiosks (Functional User Requirement).

3. Measurable Non-Functional Requirements

• System uptime must be 99.9% to ensure availability of parking fee services.
• Response time for parking price calculation requests should not exceed 2 seconds.
• The system must handle at least 200 simultaneous kiosk transactions without degradation.

4. Use Case Diagram

The use case diagram includes actors: User, Parking Management System, and Payment Gateway. Key use cases include: Purchase Parking Ticket, Calculate Price, Detect Parking Spot Status, and Process Payment. The User interacts with kiosks to purchase tickets and make payments, while the Parking Management System manages real-time parking data.

5. Use Case Specification for "Purchase a Ticket at Kiosk"

6. Sequence Diagram for "Purchase a Ticket at Kiosk"

The sequence involves the User interacting with the Kiosk, which communicates with the Demand Calculation Module to determine price, then processes payment via Payment Gateway. The Kiosk updates the parking data system and prints the ticket.

7. Architectural Style

An Event-Driven Architecture (EDA) is suitable for this parking system due to its need to respond to real-time events such as parking space occupancy and demand fluctuations. This style supports decoupled components communicating asynchronously via events, facilitating scalability and flexibility. Assumptions include the prevalence of real-time data updates and the requirement for system components to react promptly. EDA allows seamless integration of RFID sensors, kiosks, and pricing modules by using events like "Parking Spot Occupied" or "Demand Level Changed". Justification lies in its suitability for dynamic, distributed systems requiring high responsiveness and scalability.

8. Open-Closed Principle Explanation

The open-closed principle states that software entities such as classes or modules should be open for extension but closed for modification. This means you can add new functionalities without altering existing code, reducing bugs and maintaining stability. For example, in the parking system, if a new payment method (like digital wallets) needs to be added, the existing payment processing module should be extendable via new classes or interfaces without changing existing code.

9. User Interface Design Principles to Reduce Memory Load

1. Consistency: Using uniform visual styles and behaviors to avoid confusion.
2. Recognition rather than recall: Providing users with options or cues to recognize rather than remember information.
3. Minimize information: Display only necessary information at each step to avoid overload.

Example for recognition rather than recall: a kiosk presenting icons for payment options (credit card, KU Card, mobile payment) instead of requiring users to recall input methods.

10. Software Quality Dilemma

The software quality dilemma involves balancing conflicting quality attributes, such as performance versus maintainability or usability versus security. For instance, adding extensive security features might reduce system performance or complicate the user interface, impacting usability. Developers often face trade-offs to meet business needs while maintaining overall quality.

11. MTBF and Availability Explanation with Example

Mean-Time-Between-Failure (MTBF) estimates the average elapsed time between system failures, calculated as the sum of the Mean Time To Failure (MTTF) and the Mean Time To Repair (MTTR). Software availability measures the proportion of time the system is operational, calculated as (MTTF / (MTTF + MTTR)) × 100%. For example, if a system's MTTF is 100 hours and MTTR is 10 hours, then:

• MTBF = 100 hours + 10 hours = 110 hours
• Availability = (100 / 110) × 100% ≈ 90.91%

This indicates the system is operational approximately 91% of the time.

12. Testing Types

Unit testing verifies individual components or functions; integration testing checks interactions between modules; regression testing ensures that new changes do not adversely affect existing functionality. They are related sequentially: unit tests are performed first, then integration tests after modules are combined, and regression tests are conducted after modifications, to ensure overall system stability.

13. Top-Down and Bottom-Up Integration Testing

Top-down testing starts from the top-level modules and progressively integrates lower-level modules using stubs for unresolved parts. Bottom-up testing begins with lower-level modules tested first, then integrated into higher levels using drivers. For example, in a user login system, top-down testing would test the user interface first, then backend modules, whereas bottom-up would test database connection modules first, then build up.

14. Verification and Validation

Verification ensures the product is built correctly according to specifications (questioning "Are we building the system right?"). Validation checks if the final system meets user needs and requirements (questioning "Are we building the right system?"). They differ in scope; verification is often associated with reviews, inspections, and testing, while validation involves acceptance testing and user feedback.

15. Control Flow Graph and Testing

The provided program calculates standard deviation. For edge coverage, each branch (edge) in the control flow must be exercised at least once. Test paths are sequences of edges from start to end covering all edges. For edge-pair coverage, all pairs of consecutive edges are tested at least once.

Without the diagram, specific test inputs cannot be precisely provided, but generally, inputs should cover different cases: all positive numbers, including zeros, and negative values to test different branches. Expected outputs follow from standard deviation calculation formulas.

References

• Pressman, R. S. (2014). Software Engineering: A Practitioner’s Approach. McGraw-Hill Education.
• Balzer, R. (2013). Software Engineering. Springer.
• Sommerville, I. (2016). Software Engineering. Pearson Education.
• Ambler, S. (2002). The Agile Process Model. Agile Modeling.
• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes.
• ISO/IEC/IEEE 12207:2017. Systems and Software Engineering — Software Life Cycle Processes.
• Barrow, J. (2004). User Interface Design Principles. Human-Computer Interaction.
• McConnell, S. (2004). Code Complete. Microsoft Press.
• Larman, C., & Basili, V. R. (2003). Iterative and Incremental Development: A Brief History. Computer.