{"id":2411,"date":"2021-09-03T17:07:40","date_gmt":"2021-09-03T14:07:40","guid":{"rendered":"https:\/\/besoftwares.com\/en\/?p=2411"},"modified":"2024-01-24T18:10:33","modified_gmt":"2024-01-24T15:10:33","slug":"building-software-a-construction-process","status":"publish","type":"post","link":"https:\/\/besoftwares.com\/en\/building-software-a-construction-process\/","title":{"rendered":"Building Software: A Construction Process"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t

Building Software: A Construction Process<\/strong><\/h1>\n

Creating software is straightforward. Whether it’s a website or a mobile application, the key is in how it’s constructed. Similar to building a house or a laptop, software is a product that needs to meet certain construction techniques. Developing a web page or a mobile application involves several steps, leading to a technically and design-wise correct product without compromising client needs.<\/p>\n

1. Initial Mandatory Requirements:<\/strong><\/h1>\n

A. Product Owner and Stakeholders<\/strong><\/h2>\n
    \n
  • Create the “As is” process map;<\/li>\n
  • Map the flow\/process to observe, understand, and eliminate wasted time (e.g., waiting time for approval, reporting, for security reasons);<\/li>\n
  • Review and adjust the “As is” process map based on changes and process standardization;<\/li>\n
  • Create the “To be” process map.<\/li>\n<\/ul>\n

    B. Planning<\/strong><\/h1>\n

    B.1. Project Kick-off & Sprint 0<\/strong><\/h2>\n

    (Scrum Master, Product Owner, stakeholders, and\/or end-users)<\/p>\n

      \n
    • Provide a project summary and create a project breakdown;<\/li>\n
    • Define technologies and non-functional tasks;<\/li>\n
    • Define the development process, elaborate on functional parts (MVP), and prioritize them.<\/li>\n<\/ul>\n

      B.2. Product Owner, Stakeholders, and\/or End-User<\/strong><\/h2>\n
        \n
      • Create a list of requirements based on the “To be” process map;<\/li>\n
      • Ensure each requirement meets INVEST criteria;<\/li>\n
      • Define a “Done” definition for each requirement;<\/li>\n
      • Create the product backlog;<\/li>\n
      • Allocate points to each requirement to prioritize them (from high value to low value);<\/li>\n
      • Use the template “As a (user) I want (feature) so that (business benefits)” to have enough details to convert each requirement into a User Story;<\/li>\n
      • Based on priorities, create the project details map (Backbones, Walking Skeletons, and the user stories list using the MoSCoW approach).<\/li>\n<\/ul>\n

        2. Development and Testing (at Sprint Level)<\/strong><\/h1>\n

        A. Product Owner and Development Team – Sprint Planning<\/strong><\/h2>\n
          \n
        • Based on project details, prioritize user specifications to be included in the first Sprints – considering high-value and high-risk user stories;<\/li>\n
        • Product owner should have all details about user specifications to be included in the next Sprint (step-by-step workflow – work instructions – with screenshots and all relevant details) to support the development team;<\/li>\n
        • Before each Sprint Planning session, the Product Owner (and Scrum Master) fine-tune the Backlog.<\/li>\n<\/ul>\n

          B. Scrum Master and Development Team – Daily Scrum<\/strong><\/h2>\n
            \n
          • Discuss progress, encountered impediments, and what will be done\/next steps.<\/li>\n<\/ul>\n

            C. Product Owner, Development Team, Stakeholders, and\/or End-User – Sprint Review<\/strong><\/h2>\n
              \n
            • Demonstrate\/Test the product\/MVP developed during the sprint;<\/li>\n
            • Use the feedback received from stakeholders and\/or end-users to reprioritize the backlog (optional);<\/li>\n
            • Confirm the increase – if user deposits made during the sprint can be considered “Done”.<\/li>\n<\/ul>\n

              D. Development Team and Scrum Master – Sprint Retrospective<\/strong><\/h2>\n
                \n
              • Discuss gained experiences and improvement areas.<\/li>\n<\/ul>\n

                Note:<\/strong><\/p>\n

                  \n
                • After 3 Sprints, the cadence and WIP can be defined so the Scrum Master can estimate, based on the team’s velocity chart, the deadline for completing the product;<\/li>\n
                • Create a cumulative flow diagram to monitor work time vs. cycle time (as an improvement area);<\/li>\n
                • The Product Owner can cancel a Sprint only if necessary – in this case, the Sprint goal is modified;<\/li>\n
                • The Product Owner should always have all the project details from the current Sprint. Otherwise, a face-to-face discussion between the Product Owner or developer and the end-user will take place to understand project details;<\/li>\n
                • The Product Owner ensures that the product backlog is updated correctly.<\/li>\n<\/ul>\n

                  3. Integration<\/strong><\/h1>\n

                  A. Development Team<\/strong><\/p>\n

                    \n
                  • Test project details integration and fix errors.<\/li>\n<\/ul>\n

                    4. UAT \u2013 User Acceptance Test<\/strong><\/h1>\n

                    A. Product Owner, End-User, and Development Team<\/strong><\/h2>\n

                    The end-user and\/or Product Owner evaluate project details, test the product, and send confirmation to the development team.<\/p>\n

                    5. Implementation<\/strong><\/h1>\n

                    A. Product Owner, End-User, and Development Team<\/strong><\/h2>\n

                    Instructions about the project sent to the client.<\/p>\n

                    Note:<\/strong><\/p>\n

                      \n
                    • Project details: “Done” means developed, documented, and tested;<\/li>\n
                    • Releases: “Done” means no major defects or change requests remain;<\/li>\n
                    • Final project deliverables: prioritized features implemented (equivalent to two sprints without errors, meeting the end-user satisfaction score).<\/li>\n<\/ul>\n

                      Legend:<\/strong><\/p>\n

                      As is = moment T0
                      \nTo be = moment T1
                      \nDone = completed
                      \nBacklog
                      \nWork time = measures the time from when the client requests the project until they receive the deliverable
                      \nCycle time = measures the time the development team works to fulfill what the client requested<\/p>\n<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t