Design The Software Engineering Process: Phase 3 Flashcards
(17 cards)
What is the focus of the Design phase in software engineering?
The Design phase transitions from focusing on the client’s needs to planning the engineering process. This includes:
●The program itself, including:
○Design patterns.
○Algorithms.
○Data structures.
○File and database choices.
●Key design artifacts:
○Storyboard.
○Domain model.
○Critical section design.
○Risk analysis.
●The development strategy, encompassing:
○Team workflow.
○Developer’s environment.
○Staging, migration, deployment, and maintenance planning.
What are the “big ideas” in software design, and why are they important?
The “big ideas” are the high-level concepts and architectural decisions that shape the application. They are important to capture because they help control the chaos of software development and guide the planning process.
Examples of big ideas:
●Deployment diagram.
●Screen mockups.
●Algorithms.
●Data structures.
●Files and interfaces.
●Additional equipment needs.
●UML Domain Model.
●Files, databases, and APIs.
●Risk analysis.
●Critical sections.
What are the key elements of software planning, and how do they relate to the “big ideas”?
Software planning starts with:
● Bringing over the storyboard, deployment diagram, and screen mockups.
● Identifying design patterns, algorithms, data structures, files/databases, inputs/outputs.
● Designing the program with the UML Domain Model.
● Focusing on critical sections.
This process ensures that the planning is grounded in the “big ideas” and that the technical details align with the overall vision for the application.
What are the key considerations for risk analysis in software design?
Risk analysis should consider potential problems such as:
●Application Crashes: Identify scenarios that could lead to application failure and plan for graceful recovery mechanisms.
●Data Loss: Assess risks related to data corruption, accidental deletion, or unauthorized access and implement data protection measures.
●Delays: Anticipate potential delays in development, testing, or deployment and develop contingency plans.
●Hanging: Analyze situations where the application might become unresponsive and implement timeouts or alternative execution paths.
●Gracefulness: Design the application to handle errors and exceptions gracefully, providing informative messages to users.
●Security Threats (“Bad Guy”): Identify potential security vulnerabilities and implement measures to protect sensitive data and prevent unauthorized access.
●Importance: Prioritize risks based on their potential impact on the application’s functionality and user experience.
●Input Validation: Ensure that user inputs are validated to prevent invalid data from causing errors or security breaches.
●Interfacing/Communication/Passing Wrong Values: Address risks associated with data exchange between different components or systems.
●Run-time Issues: Identify and mitigate potential issues that might arise during the application’s execution, such as memory leaks or performance bottlenecks.
●Load Issues: Analyze how the application will perform under different load conditions and plan for scalability.
●Storage Issues: Address concerns related to data storage capacity, backup and recovery, and data integrity.
●Staging vs Deployment Differences: Account for potential differences between the staging and deployment environments and ensure smooth transition.
What are the main sections of a Design document?
The Design document typically includes the following sections:
● Title Page: Project name, date, author(s), and company name.
● Contents: Table of contents.
● Definitions:
○Development cycle determination.
○Engineering must-have procedures, what engineering won’t/will do, must-have technologies, best practices to use.
○Definition of success/failure from the engineering perspective, engineering constraints and assumptions.
●Solution Architecture:
○Deployment environment (Deployment Diagram, technology determination, infrastructure, and run-time environment).
○Development environment (Development Diagram, tool selection: IDE, repository, directories, tests, backups).
○Delivery environment (Staging, migration, maintenance, and support).
●Software Design:
○Storyboard.
○Code structure identification: design patterns, algorithms, data structures, files/databases, inputs/outputs.
○Programming paradigm: object-oriented programming or modular programming.
○UML Domain Model.
●Database, File, and API Definitions: Complete schemas and SQL signatures grouped by storyboard sections.
●Critical Sections: Risk analysis and mitigation algorithms documented through UML diagrams and SQL.
●Appendix: Optional documentation, references/links, standards, etc.
What are the four common software development cycles?
● Standard: A lead assigns work to developers, who create code according to specifications and the design document. The lead reviews the code’s quality and assigns new tasks.
● Paired: Similar to the standard cycle, but involves training junior developers and assigning them subtasks by senior developers. Teams consist of a lead and multiple pairs of developers.
● Spiral: Involves risk analysis and step selection with the entire team. Detailed assignments are written, work is assigned to developers, and the client is included in the review process. The cycle repeats until satisfaction is achieved.
● Mixed/Custom: Combines elements from any of the development cycle structures to create a customized approach tailored to the project, team, and client.
What are engineering procedures, and why are they important?
Engineering procedures define the standards and practices followed during development. They ensure consistency, improve collaboration, and facilitate project management.
Examples of engineering procedures:
● Daily scrum meetings.
● Regular client demos.
● Backups at each successful phase.
● Using a repository, IDE, cloud services (e.g., AWS), communication tools (e.g., Zoom, Slack).
● Common directory structure.
● Collaborative code management (pushing/merging to/from the repository, fixing code).
● Morning announcements.
● Assignments with due dates.
● Regular Gantt chart progress meetings.
What are engineering constraints and assumptions, and why should they be stated and planned for?
● Constraints: Limitations or restrictions that can impact project execution.
○ Examples: Pending holidays or vacation season, key personnel availability, project funding.
● Assumptions: Beliefs or expectations about factors that can affect the project.
○ Examples: Client availability for spiral development, timely availability of resources.
Importance:
● Stating and planning for constraints and assumptions helps create buffer times and additional fail-safe procedures.
● Addressing these factors proactively can prevent delays and ensure project success.
What are engineering success and failure statements, and why are they useful?
● Success Statements: Define criteria for determining project success.
○ Examples: Gantt chart adherence, staying within budget, client satisfaction.
● Failure Statements: Identify potential causes of project failure.
○ Examples: Delays, team dynamics issues, documentation problems.
Usefulness:
● Help track progress and identify potential problems during project reviews.
● Serve as early warning signs (“harbingers”) to trigger corrective actions.
What are the three main environments in solution architecture?
● Deployment Environment: Defines
the final delivered product and how it will look running in production.
● Development Environment: Encompasses the technology and systems surrounding the developers as they build the program.
● Delivery Environment: Includes diagrams covering staging, migration, and maintenance.
What is staging, and what are its different types?
● Definition: A process for gathering feedback from the client by demonstrating or allowing them to interact with a pre-release version of the application.
● Types:
○ Developer location: Client visits the developer’s office for a demo.
○ Running on developer’s laptop: Application is installed on the developer’s laptop and demonstrated to the client.
○ Running on client’s laptop: Application is installed and demonstrated on the client’s laptop.
○ Installing on a server that the client can access: A “staging server” is set up for the client to use and provide feedback.
○ Installing on the deployment environment: Client uses the application in a near-production environment.
What is migration, and what are the typical steps involved?
● Definition: The process of transitioning from an old software system to a new one, including data transfer and system switchover.
● Typical Steps:
1.Archive the old program and data.
2.Create a script to convert the old database to the new database format.
3.Run test queries to ensure data integrity.
4.Delete the old database.
What is maintenance, and what are the different aspects to consider?
● Definition: The ongoing support and upkeep of the software application after its deployment.
● Aspects:
○Handling client complaints.
○Regular updates.
○End-of-support procedures.
○Immediate post-deployment support for bug fixes and user assistance.
○Long-term maintenance contracts for regular updates and ongoing support.
○Out-of-contract support for bug fixes and updates on a case-by-case basis.
What are the key elements of a maintenance plan?
● Ticket System: For clients to report bugs and track progress.
● Communication Channels: Call-in, email-in, website for issue reporting.
● Progress Tracking: Dates for registration, assignment, review, and completion.
● Personnel Assignment: Names of client, developer, and reviewer.
● Communication Back to Client: Email, demo, or other appropriate methods.
● Update Method: Physical update or automatic update.
How does the analysis of deployment, development, and maintenance environments inform the Storyboard?
Analyzing these environments helps identify potential modifications or additions to the Storyboard, such as:
●Import/Export Module: For data migration and demos.
●Backup Module: For data protection and disaster recovery.
●Security Module: To address security concerns raised during the analysis of the deployment diagram.
What is a UML Domain Model, and how does it differ from a UML Class Diagram?
● UML Domain Model: A high-level visual representation of the application from a developer’s perspective, focusing on key objects, their attributes, and relationships.
● UML Class Diagram: A complete and detailed specification of all classes, their attributes, methods, and relationships.
Key Differences:
●Focus: Domain Model emphasizes important elements, while Class Diagram defines everything.
●Level of Detail: Domain Model is high-level, while Class Diagram is detailed.
●Purpose: Domain Model aids in understanding and design, while Class Diagram guides implementation.
What are the key elements of a UML Domain Model?
● Structure: Represents objects as boxes with their names.
● Attributes: List the important data elements associated with each object.
● Connectors: Show relationships between objects (e.g., association, inheritance, dependency).
● Inheritance Types: Indicate different types of inheritance relationships (e.g., generalization, specialization).
● Cardinality: Specifies the number of instances involved in a relationship.
● Aggregation: Represents a “has-a” relationship where one object contains other objects.
● Composition: A stronger form of aggregation where the contained objects depend on the container for their existence.
● Dependency: Shows that one object relies on another for its functionality.
●Labelling & Direction: Arrows and labels indicate the nature and direction of relationships.
●Constraints: Specify limitations or rules governing object behavior.
●Comments: Provide additional explanations or clarifications.
