Software Engineering

1.3.1. Hardware

1.3.2. Software

1.4.1. What are they and why are they unchanged?

1.4.2. When will you need to change them?

2.1.1. Waterfall

1. What it is
   

   \[ \text{Communication} \rightarrow \text{Planning} \rightarrow \text{Modelling} \rightarrow \text{Construction} \rightarrow \text{Deployment} \]

   • Communication is talking with the client (project initiation and requirements gathering).
   • Planning is about organizational structure (estimating, scheduling and tracking)
   • Modelling is about planning the technical implementation (analysis and design)
   • Construction is the actual implementation (code and test)
   • Deployment is giving the final product (delivery, support and feedback)
2. When to use
   
   • When requirements are stable and unlikely to change
   • When resources are available throughout.
3. Disadvantages
   
   • You have to finish a phase to move to the next one.
   • You can’t go back a phase.
   • You get an actual product only at the end of everything.

2.1.2. V-Process

1. What it is
   

   

   • Extends waterfall model by adding a testing phase.
   • It emphasizes verification and validation.
   • Testing is done in parallel to development.
   • This ensures that the product meets the specifications.
   • Each phase has specific deliverables, and the resources are well utilized.
2. When to use
   
   • Requirements are clear and fixed.
   • Scale is small
   • But you also need early defect detection.

2.1.3. Incremental

1. What it is
   

   

   • Applies linear sequences in a staggered fashion
2. Advantages
   
   • Users get working functionality early, even if the complete system isn’t ready. This provides value sooner and allows for feedback.
3. When to use
   
   • You have a large project that can be broken into modules
   • Resources can be added gradually.
   • Complexity is high but no uncertainty.

2.1.4. Rapid Application Development

1. What it is
   

   

   • Even here, you need well defined requirements.

2.1.5. Prototypic / Evolutionary Process Models

1. What it is
   
   • Prototypic
   • It’s the same waterfall model, but in a loop.
   • You do it when requirements are not well understood.
2. Disadvantages
   
   • To impress stakeholders, the prototype is often held together haphazardly, which means you haven’t considered overall software quality.

2.1.6. Spiral Model

2.2.1. 4 values of Agile

2.2.2. 12 Principles

2.2.3. Agile Scrum Methodology

1. Three Pillars
   
   • Transparency
   • Inspection
   • Adaptation
2. Scrum Artifacts
   

   Scrum artifacts are information the team and stakeholders use to detail

   • the product being developed
   • the actions to produce it, and
   • the actions performed during the project

   Product Backlog	Sprint Backlog	Increment
   List of requirements of build in product aka. list of user stories	Set of product backlog items to be implemented in current sprint	Customer deliverables which were actually delivered during a sprint

   1. Epics
      
      • They represent a big-picture vision
   2. User Stories
      
      • It’s a requirement expressed in end-user POV
      • These break epics down into actionable tasks.
      • These include functional user stories (eg. can I save my order and come back to it?) and non-functional user stories (these are technical implementations of the functions like “can I place an order at ANY time?”)
      • They comprise of 3 elements: card, conversation and confirmation
      1. Card
         
         • User stories are printed on physical cards.
         • The front tells us:
           • Who the primary stakeholder is (As a some role)
           • What effect does the story have (I want to do something)
           • What business value does this effect give the stakeholder (so that I can get some benefit)
         • The back gives us acceptance criteria (the test cases which prove that the feature works as intended).
      2. Conversation
         

         Discuss details among stakeholders

      3. Confirmation
         

         Define acceptance criteria

   3. Story Points
      
      • They help quantify the complexity of a user story
      • The numbers used are often part of the fibonacci sequence
      • Larger the number, higher the complexity and the need to be broken down into smaller user stories.
3. Events
   
   1. Backlog Grooming/Optimization
      
      • The product owner optimizes the product backlog using feedback they get from users and development team.
      • A good backlog should be DEEP:
        • Detailed Appropriately (amount of detail used to describe them ∝ how soon they’re going to be delivered)
        • Estimated (estimation of work needed to deliver ∝ how soon they’re going to be delivered)
        • Emergent (backlog adapts to customer needs)
        • Prioritized (backlog items are ranked according to business value)
   2. Sprint Planning
      
      • To make the sprint backlog, the development team conducts this meeting.
      • Specific user stores are added to the sprint backlog, from the product backlog.
   3. Daily Scrum/ Standup
      
      • It’s a meeting of about 15 minutes every day to make sure everyone is on the same page.
      • The common questions are:
        • What did I do yesterday?
        • What do I plan to do today?
        • Are there any obstacles?
   4. Sprint
      
      • The time taken to finish an increment
      • It’s typically two weeks long
      • The more complex the work is, the more shorter the sprint should be.
   5. Sprint Review
      
      • At the end of a sprint, the team showcases the increment to the stakeholders and teammates.
      • The product owner can chose if they want to release the increment or not.
      • For a 1 month long sprint, a sprint review should take not more than 4 hours.
   6. Sprint Retrospective
      
      • The team comes together to discuss what went well, what didn’t, and how things can be improved.
4. Roles
   

   Product Owner	Scrum Master	Development Team
   Client. They build the product backlog, perform backlog grooming and can also choose to release sprint increment or not	Coaches the team on scrum principles	Delivers a shippable increment during every sprint
   They are an individual not a group. Else the development team would be getting mixed guidance	They understand the work and help in improving efficiency.	They train each other and are self-organizing.
   They work with stakeholders and customers to make epics, then they work with the development team to break them down into user stories.

3.1.1. Inception

3.1.2. Elicitation

1. Collaborative Requirements Gathering
   
   • A facilitator (customer/developer) conducts a meeting to negotiate different approaches.
2. Quality Function Deployment
   
   • Translate needs of customer → technical requirements for software

   • Three types of requirements:

     Normal	Expected	Exciting
     Goals stated for product by customer	Implicit requirements that might be fundamental enough for the customer to not tell them explicitly	Requirements for features customer didn’t expect

3.1.3. Elaboration

1. Use Case Diagram
   

   Here’s an example of a use case diagram:

   • There are 4 symbols in a use case diagram:
     • Actor (Outside the box)
     • Use Cases (Ellipses)
     • Associations (lines/arrows connecting actors and use cases)
     • System Boundary (rectangle, which indicates scope)
   • In UML, if we include a label << include >> on an association/relationship, it means the use case is mandatory. If we use this label, the arrow becomes dotted.
   • Similarly if we include a label << extend >> on an association/relationship, it means the use case is optional. Here too, the arrow is dotted.
2. State Diagram
   
   • A state diagram looks like this:
3. Data Flow Diagram
   
   • Rectangle: Producer of Data
   • Circle: This is a function that takes data as input, processes it and gives output.
   • Arrows: For data flow
   • Parallel Lines: Text written inside parallel lines means it’s data stored for later use.

3.1.4. Negotiation

3.1.5. Specification

1. Functional Requirements
   
   • Functional requirements list all the functions of the website, and tells us how it works in general.
   • These are things the end-user specifically demands.
2. Non-Functional Requirements
   
   • Non-functional requirements list technical implementations of functional requirements. They could be related to performance, scalability, security, usability, etc.
   • Any performance criteria (eg. 99.9% uptime), constraints (eg. 1000 transactions per seconds) are included here.
   1. Execution Qualities
      
      • These are things observable during runtime.
      • Eg. Security, usability
   2. Evolution Qualities
      
      • These consist of things like testability, maintainability, scalability that are embodied in the static structure of the system.

3.1.6. Validation

1. Decision Tables
   

   Condition Stubs	Condition Entries	Action Stubs	Action Entries
   Variables that affect the system	Values of condition stubs	Outcomes of system	Indicators of whether an action was executed or not
   Eg. Input, User Roles, System states	Eg. yes/no, numeric, text	Eg. Updating db entry, printing a message	Eg. X, O, Blank

   Eg.

2. Decision Tree
   
   • The leaf nodes represent actions to be performed.

3.1.7. Requirements Management Task

1. Forward Traceability Matrix
   

   Maps Requirements → Test Cases and Project Deliverables

2. Backward/Reverse Traceability Matrix
   

   Maps Test Cases and Project Deliverables → Requirements

3. Bidirectional
   

   Maps both ways.

4.2.1. Cohesion

1. Functional Cohesion
   
   • Everything needed is readily available in the module.
   • This is the ideal case.
2. Sequential Cohesion
   
   • The output of an element is the input of another.
   • Data flows between the parts.
3. Communicational Cohesion
   
   • Two elements operate on the same input data or contribute towards the same output data.
4. Procedural Cohesion
   
   • It’s not data flow, but it’s still in order.
5. 
   

4.2.2. Coupling

1. Data Coupling
   
   • Only data moves around
   • The components are independent of each other
   • There is no tramp data. Tramp data is where data moves from one function to another through intermediary functions, and those functions don’t use this data.
2. Stamp Coupling
   
   • Data structures move around.
   • This contains tramp data, but it could have been for efficiency sake too.
3. Control Coupling
   
   • Modules communicate via control information/parameters.
4. External Coupling
   
   • Depends on external modules, not part of the system.
5. Common Coupling
   
   • Modules have shared data like global data structures.
   • Reusing modules or controlling data access is an issue.
6. Content Coupling
   
   • One module can modify the data of another module.
   • This is the worst form of coupling.