# ITM 305 Midterm Study Notes ## Software Development Process ### **7 Steps for Software Development** 1. **Understand the need**: Identify the problem or opportunity. 2. **Capture the vision**: Define the overall goal and purpose of the system. 3. **Define the solution**: Outline the system's functionality and scope. 4. **Communicate vision and solution**: Share the plan with stakeholders. 5. **Build the solution**: Develop the system components. 6. **Confirm the solution meets the need**: Test and validate the system. 7. **Launch the solution**: Deploy the system for use. These steps ensure a structured approach to software development, reducing errors and improving efficiency. --- ## Systems Development Life Cycle (SDLC) ### **Core Processes** 1. **Identify the problem and document objectives**: - Conduct a preliminary investigation. - Create a system vision document. - Obtain approval to start the project (meet stakeholders, approve plan and budget). 2. **Plan the project**: - Define major components (functional areas). - Assign functions to iterations. - Determine team members and their responsibilities. 3. **Discover and understand details**: - Perform fact-finding. - Develop a preliminary list of use cases and use case diagrams. - Create a preliminary list of classes and class diagrams. 4. **Design system components**: - Design the database and system architecture (e.g., browser, smartphone). - Create class diagrams and subsystem designs. 5. **Build, test, and integrate components**: - Develop the system use case by use case. - Perform unit and integration testing. 6. **Complete system testing and deploy**: - Conduct functional and user acceptance testing. - Deploy the system (possibly in parts). --- ## SDLC Approaches ### **Predictive Approach** - **Waterfall Model**: - Assumes the project can be planned in advance. - Phases are sequential: planning → analysis → design → deployment. - Requirements must be well understood with low technical risk. Assuming no changes will occur during development can lead to issues if requirements evolve. ### **Adaptive Approach** - **Iterative Model**: - Assumes flexibility is needed to adapt to changing requirements. - Suitable for projects with uncertain needs or high technical risk. For a mobile app with evolving user needs, the adaptive approach is ideal as it allows iterative updates. --- ## Key Concepts in System Development ### **Methodologies** - Guidelines for system development, specifying activities and tasks. - Includes techniques like modeling for every aspect of the project. ### **Models** - **Definition**: Abstractions of real-world aspects to simplify understanding. - **Types**: - **Textual**: Memos, reports. - **Graphical**: Diagrams (e.g., use case diagrams). - **Mathematical**: Formulas, statistics, algorithms. Use models to reduce complexity and focus on relevant aspects of the system. ### **Tools** - Software applications that assist in creating models (e.g., Visio). ### **Integrated Development Environment (IDE)** - A set of tools working together to provide a comprehensive development environment. --- ## System Requirements ### **Functional Requirements** - Activities the system **must** perform or support. ### **Non-Functional Requirements** - Characteristics the system must meet, such as: - **Usability**: User interface, help documentation. - **Reliability**: System dependability (e.g., uptime). - **Performance**: Throughput, response time. - **Security**: Data protection (e.g., encryption, HTTPS). ### **FURPS+** - An extension of FURPS that includes: - **Design constraints**: Hardware/software restrictions. - **Implementation requirements**: Programming languages, protocols. - **Interface requirements**: System interactions. - **Physical requirements**: Hardware size, power consumption. - **Supportability requirements**: Installation, updates. FURPS+ helps ensure all aspects of system requirements are covered comprehensively. --- ## Stakeholders ### **Types of Stakeholders** 1. **Internal Stakeholders**: - Within the organization. - Example: Internal auditors. 2. **External Stakeholders**: - Outside the organization. - Example: Customers, partners. ### **Operational vs. Executive Stakeholders** - **Operational**: Regularly interact with the system (e.g., accountants). - **Executive**: Use system-provided information but don’t interact directly (e.g., senior managers). --- ## Use Cases ### **Definition** - Activities the system performs in response to user requests. - Decomposes the system into a set of use cases. ### **Steps for User Goal Technique** 1. Identify potential users. 2. Classify users by roles (e.g., shipping, marketing). 3. Further classify by organizational levels (e.g., operational, executive). 4. Interview users to find their goals. 5. Create a list of use cases by user type. 6. Eliminate duplicates and inconsistencies. 7. Review the list with users and stakeholders. For an e-commerce system, a use case might be "Add item to cart." ### **Use Case Diagram** - A UML model showing relationships between use cases and actors. ### **Key Components** - **Actor**: End user interacting with the system. - **System Boundary**: Separates the application from its users. - **Automation Boundary**: Separates the computerized portion of the system from users. --- ## Event Decomposition Technique ### **Definition** - Identifies events, names use cases, and describes what the system does and when. ### **Types of Events** 1. **External Events**: Triggered by external actors (e.g., customer places an order). 2. **Temporal Events**: Triggered by time (e.g., monthly report generation). 3. **State Events**: Triggered by changes within the system (e.g., inventory drops below reorder point). ### **Steps** 1. Identify external events and corresponding use cases. 2. Identify temporal events and their triggers. 3. Identify state events and their triggers. 4. Use the perfect technology assumption to exclude system controls. Event decomposition captures a broader range of events than the user goal technique. --- ## Domain Modeling ### **Problem Domain** - The specific area of the user's business need within the system's scope. ### **"Things" in the Problem Domain** - Items users work with, such as products, customers, and invoices. - Represented as **domain classes**. ### **Techniques to Identify Domain Classes** 1. **Brainstorming**: Collaborate with users to identify relevant "things." 2. **Noun Technique**: - Identify nouns in system descriptions. - Refine the list to include only relevant items. For a library system, domain classes might include "Book," "Member," and "Loan." --- ## UML and Class Diagrams ### **Unified Modeling Language (UML)** - A standard set of constructs and notations for system modeling. - Examples: Use case diagrams, class diagrams, activity diagrams. ### **Class Diagram** - A static diagram showing the system's vocabulary and relationships. - Used for object-oriented design. ### **Associations** - Relationships between domain classes. - Types: - **Binary**: Between two classes (e.g., "Customer places Order"). - **Unary**: Between instances of the same class (e.g., "Person married to Person"). - **Ternary**: Among three classes. --- ## Key Takeaways - Follow the **7 steps of software development** for a structured approach. - Understand the **SDLC core processes** and choose the right approach (predictive vs. adaptive). - Use **FURPS+** to ensure all system requirements are addressed. - Identify stakeholders and their roles to align the system with business needs. - Leverage **UML diagrams** to model and communicate system designs effectively. - Apply techniques like **event decomposition** and **noun identification** to define use cases and domain classes. Practice creating use case diagrams and class diagrams to solidify your understanding of system modeling.