Please enable JavaScript.

Coggle requires JavaScript to display documents.

Software Engineeringsoftwareengineering - Coggle Diagram

- - - - Optimization
      - Minimizing complexity of design. Be aware of complexity of a cost
      - Different Languages
      - Improve Modifiability
      - YAGNI: Generality vs SImplicity
      - hardware and system requirements and helps in defininf the overrall system architecture. Actual documentation of requirements, agreed upon by users and developers
      - Reusing functionality: DRY
      - Design is about Code. "the map is not the territory"
      - Design has a History. 1980 structured programming. 1990 Object Oriented.. 2000/2010: Functional Programming, loose typing
    - - requirements well documented
      - product definition is stable
      - technology is understood
      - there are no ambiguous requirements
      - project is short
    - - allows for departmentalization and contro
      - Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
      - Works well for smaller projects where requirements are very well understood.
    - - does not allow much reflection or revision
      - Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.
      - No working software is produced until late during the life cycle.
      - Not a good model for complex and object-oriented projects.
      - Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
      - Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early
    - - Tech/nontech interface
        
        users use different vocabulary
      - different users, different stories
        
        know who decides
        
        talk with those who use the product
      - users always say "yes" to product features
        
        donst say no, say how much $$
        
        find good alternatives
        
        prioritize...Dont say no, say "eventually"
      - Features dont get used
        
        Build or buy?
      - users dont know what they want
  - - - Agile: a specific type of Rapid Application Development and newer than Waterfall, but not that new, which is often implemented using Scrum.
    - - Making decisions on what is known
      - Transparency: significant aspects of the process must be shared by all participants
      - Inspect: scrum users must frequently inspect artifacts and progress toward a sprint goal
      - Adaptation: Making adjustments as required
    - - Product owner
        
        Manager of the product backlog
        
        expressing, ordering backlog. Optimize the value of the work the Dev team performs. Coordinates with scrum team
        
        Organization has to respect his decisions regarding the product backlog
      - Development Team
        
        professionals who do the work of delivering a potentially
        releasable Increment of “Done” product at the end of each Sprint.
        
        They are self-organizing. No one (not even the Scrum Master) tells the Development Team
        how to turn Product Backlog into Increments of potentially releasable functionality
        
        Development Teams are cross-functional, with all of the skills as a team necessary to create
        a product Increment
        
        Scrum recognizes no titles for Development Team members other than Developer
        
        Scrum recognizes no sub-teams in the Development Team, regardless of particular domains
        that need to be addressed like testing or business analysis
      - Scrum Master
        
        The Scrum Master is responsible for ensuring Scrum is understood and enacted.
        
        Product Owner: Helps in product backlog management, product planning
        
        Dev Team: coaching, help in production, facilitating scrum events
        
        Organization: leader, planning scrum implementations
    - - Sprint: is the heart of the scrum, month or less with done usable sprint planning , daily scrums, sprint review, sprint retrospective. No changes in sprint, each sprint is a project. Product owner cancels sprint if obsolete and maybe it could still be released, everything else goes back to the backlog
      - Sprint Planning: 8 hours for a month sprint, what?, how?.
      - Daily Scrum: 15 minute timed event for dev team to think about yesterday, today and sprint goal
      - Sprint review: 4 hour meeting to review sprint
      - Sprint retrospective: Inspect personal, potentional improvements
    - - Product Backlog
      - Sprint Backlog: items selected for sprint
      - Increment: sum of pb items completed and the value of all previous sprints. must be a done