All the different artifacts in software delivery 😮💨 I'm sure there's some I have missed. Each of these could introduce problems. This is why collaboration and peer review is important throughout the entire process. Requirements - product, business, technical, acceptance criteria Design documents - architecture, database, system, UI, API, data flow diagrams, integrations Developments - source code, build scripts, config files, logs Testing - strategies, plans,, test summary reports Deployment - release notes, rollback procedures Operation and maintenance - monitoring dashboards, logging, incident reports, operational runbooks, disaster recovery, support Documentation and knowledge - API documentation, User manuals, Risk management(process)
Melissa Fisher’s Post
More Relevant Posts
-
Software delivery relies on being fed high-quality assets. What does that mean? Software Requirements – Consumed by everyone in delivery. Developers develop against them. Testers test the software against them. Test Data – Accurate and relevant test data is essential. Without it, you can’t test or develop against specific scenarios. Test Cases – The bridge between requirements and outcomes. They drive quality deliverables. We call this the Outer Loop of delivery. When the Outer Loop is deprioritised, it causes havoc across software delivery. Usually productivity and quality suffer. Catch our webinar recording here -> https://buff.ly/4hw8ZoE
To view or add a comment, sign in
-
Every workflow and process you have has a cost, including the following: - Managing your infrastructure as code as part of your development workflow - Creating project and solution design documents and getting wide feedback as part of your project workflow - Writing and running automated tests with CI/CD as part of your deployment workflow Each of these slow down delivery: - Infrastructure as code is slower than having admin permissions and making the changes directly - Gathering requirements, defining a clear definition of done, getting stakeholder feedback, etc, takes time and delays starting the implementation - CI checks take time to develop, and when they fail they prevent code from being deployed But they’re all there for a reason, because they help us get achieve a better outcome at lower overall cost/risk to the business. If your data contracts workflows don’t demonstrably lead to better outcomes and lower overall costs/risks then they are not worth doing.
To view or add a comment, sign in
-
Business Requirement Document vs Software Requirement Document
To view or add a comment, sign in
-
SRS Documentation : A Software Requirements Specification (SRS) documented that describes that the Software will do and How it will be expected to perform. It also describes the functionally the products needs to fulfill the need of all stakeholders. The elements of SRS can be simply summarized into Four Ds. 1. Define your products' purpose. 2. Describe what you are building. 3. Details the requirements. 4. Deliver it for approvals. An SRS gives you a complete picture of your entire project. It provides a single source of truth that every team involved in development will follow. It is your plan of action and keeps all your teams-from development and testing to maintenance-on the same page. #SRSDocumentation #businessanalyst #Documentation
To view or add a comment, sign in
-
𝐂𝐈/𝐂𝐃 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 Explained: The software development life cycle involves steps like development, testing, deployment, and maintenance. CI/CD automates and connects these steps for faster, more reliable releases. 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧 (𝐂𝐈): Automates build, test, and merge processes. It runs tests whenever code is submitted to find integration problems early, providing quick feedback to developers. 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 (𝐂𝐃)): Automates release processes, ensuring software can be released reliably at any time through automated workflows. It may also automate manual testing and approval steps before production release. In a typical 𝐂𝐈/𝐂𝐃 𝐩𝐢𝐩𝐞𝐥𝐢𝐧𝐞: 1. 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐬𝐮𝐛𝐦𝐢𝐭𝐬 𝐜𝐨𝐝𝐞 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐭𝐨 𝐬𝐨𝐮𝐫𝐜𝐞 𝐜𝐨𝐧𝐭𝐫𝐨𝐥 2. 𝐂𝐈 𝐬𝐞𝐫𝐯𝐞𝐫 𝐧𝐨𝐭𝐢𝐜𝐞𝐬 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐚𝐧𝐝 𝐬𝐭𝐚𝐫𝐭𝐬 𝐚 𝐛𝐮𝐢𝐥𝐝 3. 𝐂𝐨𝐝𝐞 𝐢𝐬 𝐜𝐨𝐦𝐩𝐢𝐥𝐞𝐝 𝐚𝐧𝐝 𝐭𝐞𝐬𝐭𝐞𝐝 (𝐮𝐧𝐢𝐭 𝐚𝐧𝐝 𝐢𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧 𝐭𝐞𝐬𝐭𝐬) 4. 𝐓𝐞𝐬𝐭 𝐫𝐞𝐬𝐮𝐥𝐭𝐬 𝐚𝐫𝐞 𝐫𝐞𝐩𝐨𝐫𝐭𝐞𝐝 𝐭𝐨 𝐭𝐡𝐞 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 5. 𝐈𝐟 𝐬𝐮𝐜𝐜𝐞𝐬𝐬𝐟𝐮𝐥, 𝐚𝐫𝐭𝐢𝐟𝐚𝐜𝐭𝐬 𝐚𝐫𝐞 𝐝𝐞𝐩𝐥𝐨𝐲𝐞𝐝 𝐭𝐨 𝐬𝐭𝐚𝐠𝐢𝐧𝐠 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭𝐬 6. 𝐌𝐨𝐫𝐞 𝐭𝐞𝐬𝐭𝐢𝐧𝐠 𝐦𝐚𝐲 𝐛𝐞 𝐝𝐨𝐧𝐞 𝐨𝐧 𝐬𝐭𝐚𝐠𝐢𝐧𝐠 𝐛𝐞𝐟𝐨𝐫𝐞 𝐫𝐞𝐥𝐞𝐚𝐬𝐞 7. 𝐂𝐃 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐩𝐥𝐨𝐲𝐬 𝐚𝐩𝐩𝐫𝐨𝐯𝐞𝐝 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐭𝐨 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧. Automation provides fast feedback and reduces the risk of bugs in production.
To view or add a comment, sign in
-
Long story short: case study when both requirements documentation and testing of software went wrong. lukaszpasek.com #requirements #documentation #qualityassurance #businessanalysis
To view or add a comment, sign in
-
𝗧𝗵𝗲 𝗔𝗿𝘁 𝗼𝗳 𝗪𝗿𝗮𝗽𝗽𝗲𝗿 𝗦𝗰𝗿𝗶𝗽𝘁𝘀: 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗦𝗰𝗿𝗶𝗽𝘁𝘀 𝗳𝗼𝗿 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗔𝗱𝗺𝗶𝗻𝗶𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 Let's explore wrapper scripts, optimizing your script execution and enhancing efficiency in system administration. 💻🌐 🔄 Script Execution Enhancement: Wrapper scripts act as facilitators, providing an additional layer to enhance the execution of your core scripts. They can handle pre and post-processing tasks, making your scripts more versatile. 🛠️ Logging and Monitoring Integration: Incorporate logging and monitoring features into wrapper scripts. This ensures that you have a comprehensive view of script activities, facilitating troubleshooting and performance analysis. 🔍 Error Handling Expertise: Wrapper scripts excel in error handling. They can add sophistication to error detection, reporting, and recovery mechanisms, ensuring the robustness of your automated processes. 🌐 My Perspective: Wrapper scripts are not just an add-on; they're strategic components in optimizing script workflows. They empower administrators to orchestrate complex processes with simplicity. How have wrapper scripts streamlined your script execution workflows? Share your insights as we reinforce the role of efficiency in system administration. 🤝
To view or add a comment, sign in
-
Software Requirements Specification (SRS) Template Example 🌟 #SRS #Template #BusinessAnalysis #ProjectManagement
To view or add a comment, sign in
-
A high-level writeup on taking contract-driven, configuration-driven, context-driven approach to API lifecycle management.
To view or add a comment, sign in
-
Software Requirement specification(SRS) Expectations from SRS document * Define the functions of the systems * Hardware/Software Functional Partitioning * Define the Performance Specification * Hardware/Software Performance Partitioning * Define Safety Requirements * Define the User Interface (user’s manual) * Provide Installation Drawings/Instructions * Software Requirement specification template #businessanalyst #businessanalysis #learning #softwaresolutions 72/100
To view or add a comment, sign in