One of the most critical activities in software product development is the decisional process that assigns features to subsequent releases under technical, resource, risk, and budget constraints. This decision-centric process is referred to as software release planning (SRP).
This briefing will expose a state of the art on SRP. A survey of the most relevant approaches will be presented. Emphasis will be made on their applicability (concerning e.g. type of development process and type of system, tool support and degree of validation in industry. One of these approaches, EVOLVE, will be analysed in detail.
The briefing is addressed to a wide audience. For researchers, an updated state of the art will be exposed, a particular method will be explored in depth, and the presentation will rely on scientific grounds. For practitioners, the practical dimension of SRP will be present. For educators, the briefing will provide the basis for developing course material.
The document outlines an effective software release management strategy with multiple layers and branching models. It discusses establishing rigorous development, build, test, and deployment cycles with common environments. It also recommends moving to continuous integration and deployment with tools and processes to support rapid defect detection. Higher level branches have stricter quality criteria than lower ones, with mainline and release branches intended for stable, tested code. The strategy aims to speed delivery, increase quality, reduce costs, and support scalable, efficient development.
Here is the FMEA analysis for the LTE Release Management process:
1. Execute Patch Release Testing
- Incomplete testing due to time constraints
- Defects passed through to next stage
8
- Lack of test resources/capacity
- Complexity of software
- Timeboxed testing
7
- Test automation
- Peer review of test cases
6
336
2. Patch under Pilot
- Defects identified in Pilot phase
- Delays resolution and rollout
7
- Insufficient Pilot scope/scale
- Quality of testing prior to Pilot
6
- Staged Pilot rollout
-
Software release management involves overseeing the integration and flow of software development, testing, deployment, and support. A typical software release cycle includes pre-alpha, alpha, beta, release candidate, general release, and end of life phases. Release management ensures reliable planning, scheduling, and deployment of software releases to end users. It is a growing discipline important for coordinating activities between development, testing, and release teams and addressing challenges like software defects, changes, new features, and deployment risks across different platforms and environments. An effective release manager acts as a coordinator, gatekeeper, diplomat, and point of contact to balance requirements from various stakeholders and customers.
Taking Release Management to the Next LevelXebiaLabs
The document discusses how release management needs to evolve to enable development and operations teams to deliver features and functions faster. It notes that while development and operations teams are adapting practices like DevOps and continuous delivery, release management practices have not kept up. The missing step is application release automation, which can help achieve both speed and quality by automating manual release processes and enabling controlled continuous value delivery. A demonstration of these capabilities will be provided.
Releases are risky. Often homegrown scripts, manual steps, and runbook orchestrations contribute to the risks involved with application releases.Having a controlled release process can strengthen release management by ensuring quality, reducing manual tasks, deploying applications consistently across environments, and more.Development teams, making the changes to meet customers’ needs, realized that they could not keep up with the increased demand. Many of those teams turned to Agile methodologies. Agile methodologies would help developers create a steady stream of features and solve customer’s problems as they arose. Agile solutions allowed developers to make rapid changes. However, organizations were unable to achieve the full benefit of Agile. Legacy deployment processes delayed the release of the applications because they were built for infrequent releases.
General description of Release Management within an ITIL-based IT (Infra) Services organization. Find me at https://nl.linkedin.com/in/tijsvanvelthoven for more information
Release management is a software engineering process to oversee development, testing, deployment and support of software releases. The purpose is to ensure a consistent deployment method across projects. Key aspects include planning releases, testing, developing distribution procedures, and coordinating communication about releases. The Digité application provides a project-level release management module for robust planning and execution of releases with capabilities like adding, viewing, copying and tagging releases to items like defects.
The document outlines an effective software release management strategy with multiple layers and branching models. It discusses establishing rigorous development, build, test, and deployment cycles with common environments. It also recommends moving to continuous integration and deployment with tools and processes to support rapid defect detection. Higher level branches have stricter quality criteria than lower ones, with mainline and release branches intended for stable, tested code. The strategy aims to speed delivery, increase quality, reduce costs, and support scalable, efficient development.
Here is the FMEA analysis for the LTE Release Management process:
1. Execute Patch Release Testing
- Incomplete testing due to time constraints
- Defects passed through to next stage
8
- Lack of test resources/capacity
- Complexity of software
- Timeboxed testing
7
- Test automation
- Peer review of test cases
6
336
2. Patch under Pilot
- Defects identified in Pilot phase
- Delays resolution and rollout
7
- Insufficient Pilot scope/scale
- Quality of testing prior to Pilot
6
- Staged Pilot rollout
-
Software release management involves overseeing the integration and flow of software development, testing, deployment, and support. A typical software release cycle includes pre-alpha, alpha, beta, release candidate, general release, and end of life phases. Release management ensures reliable planning, scheduling, and deployment of software releases to end users. It is a growing discipline important for coordinating activities between development, testing, and release teams and addressing challenges like software defects, changes, new features, and deployment risks across different platforms and environments. An effective release manager acts as a coordinator, gatekeeper, diplomat, and point of contact to balance requirements from various stakeholders and customers.
Taking Release Management to the Next LevelXebiaLabs
The document discusses how release management needs to evolve to enable development and operations teams to deliver features and functions faster. It notes that while development and operations teams are adapting practices like DevOps and continuous delivery, release management practices have not kept up. The missing step is application release automation, which can help achieve both speed and quality by automating manual release processes and enabling controlled continuous value delivery. A demonstration of these capabilities will be provided.
Releases are risky. Often homegrown scripts, manual steps, and runbook orchestrations contribute to the risks involved with application releases.Having a controlled release process can strengthen release management by ensuring quality, reducing manual tasks, deploying applications consistently across environments, and more.Development teams, making the changes to meet customers’ needs, realized that they could not keep up with the increased demand. Many of those teams turned to Agile methodologies. Agile methodologies would help developers create a steady stream of features and solve customer’s problems as they arose. Agile solutions allowed developers to make rapid changes. However, organizations were unable to achieve the full benefit of Agile. Legacy deployment processes delayed the release of the applications because they were built for infrequent releases.
General description of Release Management within an ITIL-based IT (Infra) Services organization. Find me at https://nl.linkedin.com/in/tijsvanvelthoven for more information
Release management is a software engineering process to oversee development, testing, deployment and support of software releases. The purpose is to ensure a consistent deployment method across projects. Key aspects include planning releases, testing, developing distribution procedures, and coordinating communication about releases. The Digité application provides a project-level release management module for robust planning and execution of releases with capabilities like adding, viewing, copying and tagging releases to items like defects.
Watch the recorded version of this Webinar here:
Curious about Continuous Integration? Tune in!
Continuous Integration (CI), which is a big part of continuous delivery, is the concept of continuously building and testing software using an automated process. We have learned that utilizing CI could help us catch bugs earlier, enable better visibility, reduce repetitive processes, enable the development team to produce deployable products at a moment's notice, and reduce risk overall.
These slides will identify the various levels of continuous integration and delivery with regards to a release maturity of the development team or parent organization.
Release Management: Successful Software Releases Start with a Planconnielharper
This document discusses the importance of release planning for successful software releases. It notes that even with agile development, a release plan is needed to coordinate releasing software to users. The document outlines different types of release cycles including time-based, feature-based, and market demand-based. It also discusses factors to consider when deciding on a release cycle. Additionally, it provides details on what should be included in a release plan such as goals, features, milestones, responsibilities, dependencies, and risks. The document stresses the importance of communication and ensuring product readiness to have successful software releases.
The document discusses release management in BMC Remedy ITSM 7.6. It describes the release request lifecycle including stages like initiate, plan, build, test, deployment, and close down. It outlines roles like release coordinator, change manager, and activity assignee. It provides details on how to create release requests, add related change requests and activities, and move through the approval phases. The webinar aims to help users understand release management functionality in BMC Remedy.
The document discusses using the Rational Unified Process (RUP) for small projects. It describes a case study of a Norwegian software company that used RUP on four projects but with mixed results due to a lack of guidance. Interviews found RUP was used inconsistently across projects and disciplines. This suggests tailoring RUP specifically for each project is important for successful adoption on small projects. Guidelines are provided for iterative development using RUP, such as planning iterations in detail and addressing risks early.
The document summarizes the nine disciplines of the Rational Unified Process (RUP):
1) The Business Modeling Discipline involves understanding the business and domain model.
2) The Requirements Discipline involves eliciting, documenting, and agreeing on system requirements.
3) The Analysis and Design Discipline involves analyzing requirements and designing the system architecture and components.
4) The Implementation Discipline involves transforming the design into code and unit testing.
5) The Test Discipline involves defining and executing test plans and cases.
6) The Deployment Discipline involves planning and executing the system deployment.
7) The Configuration and Change Management Discipline involves managing versions and changes
The document discusses several software development life cycle (SDLC) models:
- Waterfall model involves sequential phases of requirements, design, implementation, testing and deployment with defined deliverables for each phase. It works well for stable requirements but lacks flexibility.
- V-shaped model emphasizes verification and validation testing in parallel with development phases. It focuses on planning testing in early phases.
- Prototyping model involves building prototypes to clarify requirements with user feedback before final development.
- RAD model focuses on rapid delivery through time-boxed iterations with customer involvement.
- Incremental model prioritizes and implements requirements in groups to provide early functionality.
- Spiral model combines prototyping, risk analysis
The document discusses software deployment principles and practices, outlining four key principles: repeatable builds, consistent environments, autonomous packages, and ease of doing/undoing releases. It provides details on each principle and how they can be achieved, such as through versioning of artifacts, baselining components together, and developing automated and documented processes.
This document discusses different system development life cycle (SDLC) models, including waterfall, V-shape, iterative, spiral, and agile. It provides an overview of the key steps and phases in each model, as well as their pros and cons. When to use each model is also addressed. The agile model and scrum framework are discussed in more detail.
The document provides an overview of various software development life cycle (SDLC) models including Waterfall, V-Shaped, Prototyping, Rapid Application Development (RAD), Incremental, Spiral, Agile approaches like Extreme Programming (XP) and Feature Driven Development (FDD). It describes the key phases, strengths, weaknesses and scenarios where each model is best suited. The SDLC models range from traditional plan-driven to more adaptive approaches and the choice of model depends on project factors like requirements, risks, schedules and team preferences.
The document discusses the Software Development Life Cycle (SDLC), which is a framework for developing software in a systematic and efficient manner. It involves several phases from planning and requirements analysis to development, testing, deployment, and maintenance. SDLC helps estimate timelines, test software thoroughly, and develop applications in a disciplined way. The key phases include initiation, planning, requirements analysis, design, development, integration and testing, implementation, deployment, and maintenance.
The document provides an overview of the Rational Unified Process (RUP). It defines software engineering and how software development lifecycles (SDLCs) enable a systematic approach. RUP is described as a library of SDLC processes and a platform for delivering any SDLC methodology. Key aspects of RUP include its iterative lifecycle, unified method architecture (UMA) for representing processes and content, and how it can be customized and provides guidance for software teams. The document aims to introduce readers to RUP's principles and components.
The document discusses various software engineering methodologies including the waterfall model, iterative model, Rational Unified Process (RUP), and agile methodologies like extreme programming (XP) and Scrum. It provides detailed descriptions of each methodology's phases and workflows. The waterfall model divides the life cycle into sequential phases while iterative models allow revisiting previous phases. RUP includes inception, elaboration, construction, and transition phases. Agile prioritizes customer satisfaction, working software, and flexibility over documentation and processes.
Automation of Release and Deployment Management - MavericMaveric Systems
This presentation highlights why automation platforms for application release and deployment are becoming increasingly vital for global enterprises and explores the specific requirements of such a platform in order for it to prove beneficial, effective and offer a substantial return on investment.
This document outlines and compares five software development models: waterfall, iterative, V-shaped, spiral, and extreme programming. Each model is described in terms of its phases or activities, advantages, and disadvantages. The waterfall model involves sequential non-overlapping phases from requirements to maintenance. Iterative development divides a project into smaller parts with feedback between phases. The V-shaped model emphasizes testing at each stage. The spiral model performs risk analysis and prototypes in iterative loops. Extreme programming focuses on small incremental releases and pair programming. In conclusion, the author states that different models suit different projects and each tries to improve on previous limitations.
The document outlines the steps in the software development life cycle (SDLC), including initial communication, requirement gathering, feasibility analysis, system analysis, software design, coding, testing, integration, implementation, and maintenance. It describes each step in the SDLC process such as gathering requirements from stakeholders, analyzing feasibility, designing the software system, writing code, testing at various stages, integrating the software, implementing it for users, and maintaining it with updates. The SDLC provides a framework for software development projects by describing the key activities that occur at each phase.
The document describes the system development life cycle (SDLC), which is a process used to develop, implement, and retire information systems through several steps: initiation, analysis, design, implementation, and maintenance. It involves analyzing user needs, designing the system, coding, testing, implementation, and maintenance. The waterfall model is presented as a common SDLC approach, consisting of sequential phases from requirements analysis through maintenance. Other SDLC models mentioned include iterative, spiral, object-oriented, rapid application development, and joint application development.
The document discusses several software development life cycle (SDLC) models including waterfall, V-shaped, prototyping, rapid application development (RAD), incremental, spiral, and timeboxing. It provides descriptions of each model including typical steps, strengths, weaknesses, and when each model is best suited. It also discusses capability maturity model (CMM) levels and how changing the lifecycle model can impact development speed, quality, visibility, overhead, risk, and customer relations.
The document provides an overview of the Rational Unified Process (RUP). It discusses that the RUP is a software engineering process that guides software development organizations. The RUP is designed and delivered like software, with regular updates. It captures many modern best practices such as iterative development, managing requirements, and continuously verifying quality. The RUP has a defined structure using phases, iterations, and disciplines to group activities. It can also be customized to meet an organization's specific needs.
You will learn about the technical approach the University of California, Office of the President pursued for one of the world’s largest PeopleSoft HCM 9.2 implementations hosted at Oracle Managed Cloud Services – UCPath.
Learn about their initiative, and hear their approach for an effective collaboration with Smart ERP Solutions, Inc. to meet many technical objectives in the design, implementation, and maintenance of the PeopleSoft HCM solution in this complex implementation. This includes how UCPath leveraged the PeopleSoft Selective Adoption Model.
Alliance 2017 3891-University of California | Office of The President People...Smart ERP Solutions, Inc.
Jeffery Wong, Senior Applications Manager, PeopleSoft Systems Group - University of California System. Mr. Wong discusses the pragmatic approach the University of California Office of the President (UCOP) pursued for one of the world’s largest PeopleSoft HCM 9.2 implementations hosted by Oracle Managed Cloud Services, for the UCPath project (UC Payroll, Academic Personnel, Timekeeping & Human Resources).
Watch the recorded version of this Webinar here:
Curious about Continuous Integration? Tune in!
Continuous Integration (CI), which is a big part of continuous delivery, is the concept of continuously building and testing software using an automated process. We have learned that utilizing CI could help us catch bugs earlier, enable better visibility, reduce repetitive processes, enable the development team to produce deployable products at a moment's notice, and reduce risk overall.
These slides will identify the various levels of continuous integration and delivery with regards to a release maturity of the development team or parent organization.
Release Management: Successful Software Releases Start with a Planconnielharper
This document discusses the importance of release planning for successful software releases. It notes that even with agile development, a release plan is needed to coordinate releasing software to users. The document outlines different types of release cycles including time-based, feature-based, and market demand-based. It also discusses factors to consider when deciding on a release cycle. Additionally, it provides details on what should be included in a release plan such as goals, features, milestones, responsibilities, dependencies, and risks. The document stresses the importance of communication and ensuring product readiness to have successful software releases.
The document discusses release management in BMC Remedy ITSM 7.6. It describes the release request lifecycle including stages like initiate, plan, build, test, deployment, and close down. It outlines roles like release coordinator, change manager, and activity assignee. It provides details on how to create release requests, add related change requests and activities, and move through the approval phases. The webinar aims to help users understand release management functionality in BMC Remedy.
The document discusses using the Rational Unified Process (RUP) for small projects. It describes a case study of a Norwegian software company that used RUP on four projects but with mixed results due to a lack of guidance. Interviews found RUP was used inconsistently across projects and disciplines. This suggests tailoring RUP specifically for each project is important for successful adoption on small projects. Guidelines are provided for iterative development using RUP, such as planning iterations in detail and addressing risks early.
The document summarizes the nine disciplines of the Rational Unified Process (RUP):
1) The Business Modeling Discipline involves understanding the business and domain model.
2) The Requirements Discipline involves eliciting, documenting, and agreeing on system requirements.
3) The Analysis and Design Discipline involves analyzing requirements and designing the system architecture and components.
4) The Implementation Discipline involves transforming the design into code and unit testing.
5) The Test Discipline involves defining and executing test plans and cases.
6) The Deployment Discipline involves planning and executing the system deployment.
7) The Configuration and Change Management Discipline involves managing versions and changes
The document discusses several software development life cycle (SDLC) models:
- Waterfall model involves sequential phases of requirements, design, implementation, testing and deployment with defined deliverables for each phase. It works well for stable requirements but lacks flexibility.
- V-shaped model emphasizes verification and validation testing in parallel with development phases. It focuses on planning testing in early phases.
- Prototyping model involves building prototypes to clarify requirements with user feedback before final development.
- RAD model focuses on rapid delivery through time-boxed iterations with customer involvement.
- Incremental model prioritizes and implements requirements in groups to provide early functionality.
- Spiral model combines prototyping, risk analysis
The document discusses software deployment principles and practices, outlining four key principles: repeatable builds, consistent environments, autonomous packages, and ease of doing/undoing releases. It provides details on each principle and how they can be achieved, such as through versioning of artifacts, baselining components together, and developing automated and documented processes.
This document discusses different system development life cycle (SDLC) models, including waterfall, V-shape, iterative, spiral, and agile. It provides an overview of the key steps and phases in each model, as well as their pros and cons. When to use each model is also addressed. The agile model and scrum framework are discussed in more detail.
The document provides an overview of various software development life cycle (SDLC) models including Waterfall, V-Shaped, Prototyping, Rapid Application Development (RAD), Incremental, Spiral, Agile approaches like Extreme Programming (XP) and Feature Driven Development (FDD). It describes the key phases, strengths, weaknesses and scenarios where each model is best suited. The SDLC models range from traditional plan-driven to more adaptive approaches and the choice of model depends on project factors like requirements, risks, schedules and team preferences.
The document discusses the Software Development Life Cycle (SDLC), which is a framework for developing software in a systematic and efficient manner. It involves several phases from planning and requirements analysis to development, testing, deployment, and maintenance. SDLC helps estimate timelines, test software thoroughly, and develop applications in a disciplined way. The key phases include initiation, planning, requirements analysis, design, development, integration and testing, implementation, deployment, and maintenance.
The document provides an overview of the Rational Unified Process (RUP). It defines software engineering and how software development lifecycles (SDLCs) enable a systematic approach. RUP is described as a library of SDLC processes and a platform for delivering any SDLC methodology. Key aspects of RUP include its iterative lifecycle, unified method architecture (UMA) for representing processes and content, and how it can be customized and provides guidance for software teams. The document aims to introduce readers to RUP's principles and components.
The document discusses various software engineering methodologies including the waterfall model, iterative model, Rational Unified Process (RUP), and agile methodologies like extreme programming (XP) and Scrum. It provides detailed descriptions of each methodology's phases and workflows. The waterfall model divides the life cycle into sequential phases while iterative models allow revisiting previous phases. RUP includes inception, elaboration, construction, and transition phases. Agile prioritizes customer satisfaction, working software, and flexibility over documentation and processes.
Automation of Release and Deployment Management - MavericMaveric Systems
This presentation highlights why automation platforms for application release and deployment are becoming increasingly vital for global enterprises and explores the specific requirements of such a platform in order for it to prove beneficial, effective and offer a substantial return on investment.
This document outlines and compares five software development models: waterfall, iterative, V-shaped, spiral, and extreme programming. Each model is described in terms of its phases or activities, advantages, and disadvantages. The waterfall model involves sequential non-overlapping phases from requirements to maintenance. Iterative development divides a project into smaller parts with feedback between phases. The V-shaped model emphasizes testing at each stage. The spiral model performs risk analysis and prototypes in iterative loops. Extreme programming focuses on small incremental releases and pair programming. In conclusion, the author states that different models suit different projects and each tries to improve on previous limitations.
The document outlines the steps in the software development life cycle (SDLC), including initial communication, requirement gathering, feasibility analysis, system analysis, software design, coding, testing, integration, implementation, and maintenance. It describes each step in the SDLC process such as gathering requirements from stakeholders, analyzing feasibility, designing the software system, writing code, testing at various stages, integrating the software, implementing it for users, and maintaining it with updates. The SDLC provides a framework for software development projects by describing the key activities that occur at each phase.
The document describes the system development life cycle (SDLC), which is a process used to develop, implement, and retire information systems through several steps: initiation, analysis, design, implementation, and maintenance. It involves analyzing user needs, designing the system, coding, testing, implementation, and maintenance. The waterfall model is presented as a common SDLC approach, consisting of sequential phases from requirements analysis through maintenance. Other SDLC models mentioned include iterative, spiral, object-oriented, rapid application development, and joint application development.
The document discusses several software development life cycle (SDLC) models including waterfall, V-shaped, prototyping, rapid application development (RAD), incremental, spiral, and timeboxing. It provides descriptions of each model including typical steps, strengths, weaknesses, and when each model is best suited. It also discusses capability maturity model (CMM) levels and how changing the lifecycle model can impact development speed, quality, visibility, overhead, risk, and customer relations.
The document provides an overview of the Rational Unified Process (RUP). It discusses that the RUP is a software engineering process that guides software development organizations. The RUP is designed and delivered like software, with regular updates. It captures many modern best practices such as iterative development, managing requirements, and continuously verifying quality. The RUP has a defined structure using phases, iterations, and disciplines to group activities. It can also be customized to meet an organization's specific needs.
You will learn about the technical approach the University of California, Office of the President pursued for one of the world’s largest PeopleSoft HCM 9.2 implementations hosted at Oracle Managed Cloud Services – UCPath.
Learn about their initiative, and hear their approach for an effective collaboration with Smart ERP Solutions, Inc. to meet many technical objectives in the design, implementation, and maintenance of the PeopleSoft HCM solution in this complex implementation. This includes how UCPath leveraged the PeopleSoft Selective Adoption Model.
Alliance 2017 3891-University of California | Office of The President People...Smart ERP Solutions, Inc.
Jeffery Wong, Senior Applications Manager, PeopleSoft Systems Group - University of California System. Mr. Wong discusses the pragmatic approach the University of California Office of the President (UCOP) pursued for one of the world’s largest PeopleSoft HCM 9.2 implementations hosted by Oracle Managed Cloud Services, for the UCPath project (UC Payroll, Academic Personnel, Timekeeping & Human Resources).
This document provides an overview of the Agile Software Architecture course offered by NISI in 2017. The course consists of 8 sessions covering topics like agile architecture, architectural decision making, quality attributes, feedback and monitoring, and architecture evolution. It is taught by professors from Utrecht University and industry architects. The goal is to help architects think more strategically and discuss real-world cases. Participants come from various roles and companies in consulting, transportation, ERP, public sector and healthcare. They hope to improve their skills and address challenges regarding privacy, security and agility. More information can be found on the course website or by contacting the lead instructor, Slinger Jansen.
This document summarizes Nick Boyd's MS ISE thesis project applying Lean/Six Sigma principles to optimize AEP's power distribution network. It describes the Define, Measure, Analyze, Improve, and Control phases. In Define, critical customer needs were identified through interviews. In Measure, existing databases were analyzed to establish baselines. Analyze involved validating data and exploring correlations. Improvement ideas focused on database accuracy and workflow. The project aimed to enhance AEP's ability to measure, analyze, and improve network reliability over time.
The document discusses software engineering and the Unified Software Development Process (USDP). It describes the USDP which includes phases of inception, elaboration, construction, and transition. Each phase involves iterations where requirements, analysis, design, implementation, and testing are done. The goal of each iteration is to produce an executable increment that is tested and evaluated.
This document provides an overview of software engineering. It discusses what software engineering is, common software development process models like waterfall, spiral, agile development, and the Unified Software Development Process (USDP). The USDP follows an iterative approach with phases for inception, elaboration, construction, and transition. Each phase has milestones and the process involves iterations where requirements, design, coding, and testing are done to create executable increments.
Kelis king - software engineering and best practicesKelisKing
Kelis King offer involve conducting system testing to ensure correct operation, and integration testing to ensure the system integrates correctly with other required systems, such as databases.
Scalable and Cost-Effective Model-Based Software Verification and TestingLionel Briand
This document describes research on using model-based techniques to generate stress test cases for embedded software. A constraint programming approach is used to model the software system, hardware platform, and performance requirements. The model includes properties of threads, activities, and the scheduling policy. The approach searches for values of tunable parameters, such as delays, that maximize CPU usage while satisfying constraints, in order to evaluate the system under worst-case conditions and help verify that it meets safety standards. The generated test cases effectively stress the system by selecting parameter values that guide the execution towards maximum resource consumption.
eCIO PPT Plan of Action for a Systems Integrations (SAP) ProjectDavid Niles
1. The document outlines the process for developing a systems integration plan for a large-scale integration program, including defining the purpose and approach, identifying challenges, and next steps.
2. It describes assessing over 35 applications for integration or decommissioning across various technologies and projects. Developing the plan involves mapping requirements, establishing a release schedule, and defining integration work packages.
3. Challenges include blending old and new processes, addressing various technologies and tools, and extracting functionality from applications to be decommissioned. The approach will utilize ASAP methodology and involve information discovery, blueprinting, and solution mapping.
Spago4Q and the Quest nD Model: an Open Source Solution for Software Performa...SpagoWorld
The presentation by Claudio A. Ardagna, Ernesto Damiani, Fulvio Frati, Sergio Oltolina, Mauro Regoli, Gabriele Ruffatti, was shown during the international conference on open source software OSS 2010, which took place at Notre Dame University, Indiana, USA, from 30th May to 2nd June 2010.
This document outlines the 10 step process for software project planning. It begins with selecting the project and identifying its scope and objectives. It then covers identifying the project infrastructure, analyzing project characteristics, and identifying products and activities. Steps also include estimating effort for each activity, identifying risks, allocating resources, and reviewing/publicizing the plan. Execution then involves lower level planning. The document also discusses software effort estimation techniques such as algorithmic models, expert judgment, analogy, and top-down and bottom-up approaches.
Software Architecture Evaluation: A Systematic Mapping StudySofia Ouhbi
Sofia Ouhbi presented a systematic mapping study on software architecture evaluation approaches at the 13th International Conference on Evaluation of Novel Approaches to Software Engineering in Funchal, Madeira, Portugal. The study analyzed 60 papers on software architecture evaluation to identify key publication sources, trends over time, research types, validation methods, evaluation approaches, quality models used, and description models. The results showed that journals and conferences are the main publication sources, interest peaked in the late 2000s and has declined recently, case studies are common validation methods, and quality attributes like performance and maintainability are frequently evaluated using models like the ISO 9126.
SGCI - The Science Gateways Community Institute: International Collaboration ...Sandra Gesing
Science gateways - also called virtual research environments or virtual labs - allow science and engineering communities to access shared data, software, computing services, instruments, and other resources specific to their disciplines. The US Science Gateways Community Institute (SGCI), opened in August 2016, provides free resources, services, experts, and ideas for creating and sustaining science gateways. It offers five areas of services to the science gateway developer and user communities: the Incubator, Extended Developer Support, the Scientific Software Collaborative, Community Engagement and Exchange, and Workforce Development. While all these services are available to US-based communities, the Incubator, the Scientific Software Collaborative and the Community Engagement and Exchange serve also the international communities. SGCI aims at supporting beyond borders on international scale with diverse measures and to form and deepen collaborations with partner organizations and coalitions beneficial and/or related to the science gateways community. Research topics are independent of national borders and researchers spread worldwide can benefit from each other’s research results, software, data and from lessons learned — via online materials and publications or at international events. The gateway community has benefitted from this type of exchange for years and one mission of SGCI is to support the international community. This talk will present related work describing the benefits of international collaborations generally, and specifically as they relate to science gateways. It will go into detail regarding SGCI’s ongoing work on an international scale and SGCI's work planned in the near future to foster collaborations under consideration of challenges such as different timezones and long distances between collaborators.
Primavera _ Richard Houghton _ Integrated Project Control Systems.pdfInSync2011
Richard Houghton discusses implementing an integrated project control system (PCS) to integrate their financial, estimating, and planning systems. Currently, they use disparate standalone systems with data entered multiple times. The PCS would use a central database to eliminate duplicate data entry and generate reports and metrics. It is expected to improve forecasting, performance measurement, risk management, and benchmarking. Potential benefits include increased on-time and on-budget project delivery as well as performance improvements. Considerations include stakeholder buy-in, clear processes and objectives, and user adoption and training.
The document discusses the system development life cycle (SDLC), which includes preliminary investigation, requirements analysis, system design, software development, system testing, and implementation and maintenance. It describes the purpose and history of SDLC as emerging in the 1960s to address the "software crisis". It also outlines the main steps and activities in each phase of the SDLC process.
The document discusses the system development life cycle (SDLC), which involves 6 main steps: 1) preliminary investigation, 2) requirements analysis, 3) system design, 4) system acquisition and development, 5) system testing, and 6) implementation and maintenance. It describes each step in detail, including gathering user requirements, designing and selecting a software model, testing the system, training users, and evaluating the results. The SDLC aims to efficiently develop high-quality software through a structured process of analysis, design, implementation, and maintenance activities.
This presentation raises some challenges for the OSGeo community addressing some aspects of the foundation pillars; in particular the incubation process, the Open Geoscience and the ethics are discussed to raise awareness and discussion.
The document discusses the Rational Unified Process (RUP), an iterative software development process for building object-oriented systems. It is based on commonly accepted best practices like iterative development. The RUP combines requirements, analysis, design, and testing activities into a series of timed iterations. Each iteration results in an integrated and tested increment of functionality. The RUP aims to deliver early and continuous value through practices like iterative development, user involvement, and risk-driven development.
Similar to Technical briefing on Software Release Planning (20)
Neo4j - Product Vision and Knowledge Graphs - GraphSummit ParisNeo4j
Dr. Jesús Barrasa, Head of Solutions Architecture for EMEA, Neo4j
Découvrez les dernières innovations de Neo4j, et notamment les dernières intégrations cloud et les améliorations produits qui font de Neo4j un choix essentiel pour les développeurs qui créent des applications avec des données interconnectées et de l’IA générative.
E-commerce Application Development Company.pdfHornet Dynamics
Your business can reach new heights with our assistance as we design solutions that are specifically appropriate for your goals and vision. Our eCommerce application solutions can digitally coordinate all retail operations processes to meet the demands of the marketplace while maintaining business continuity.
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
Odoo ERP software
Odoo ERP software, a leading open-source software for Enterprise Resource Planning (ERP) and business management, has recently launched its latest version, Odoo 17 Community Edition. This update introduces a range of new features and enhancements designed to streamline business operations and support growth.
The Odoo Community serves as a cost-free edition within the Odoo suite of ERP systems. Tailored to accommodate the standard needs of business operations, it provides a robust platform suitable for organisations of different sizes and business sectors. Within the Odoo Community Edition, users can access a variety of essential features and services essential for managing day-to-day tasks efficiently.
This blog presents a detailed overview of the features available within the Odoo 17 Community edition, and the differences between Odoo 17 community and enterprise editions, aiming to equip you with the necessary information to make an informed decision about its suitability for your business.
SMS API Integration in Saudi Arabia| Best SMS API ServiceYara Milbes
Discover the benefits and implementation of SMS API integration in the UAE and Middle East. This comprehensive guide covers the importance of SMS messaging APIs, the advantages of bulk SMS APIs, and real-world case studies. Learn how CEQUENS, a leader in communication solutions, can help your business enhance customer engagement and streamline operations with innovative CPaaS, reliable SMS APIs, and omnichannel solutions, including WhatsApp Business. Perfect for businesses seeking to optimize their communication strategies in the digital age.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
Graspan: A Big Data System for Big Code AnalysisAftab Hussain
We built a disk-based parallel graph system, Graspan, that uses a novel edge-pair centric computation model to compute dynamic transitive closures on very large program graphs.
We implement context-sensitive pointer/alias and dataflow analyses on Graspan. An evaluation of these analyses on large codebases such as Linux shows that their Graspan implementations scale to millions of lines of code and are much simpler than their original implementations.
These analyses were used to augment the existing checkers; these augmented checkers found 132 new NULL pointer bugs and 1308 unnecessary NULL tests in Linux 4.4.0-rc5, PostgreSQL 8.3.9, and Apache httpd 2.2.18.
- Accepted in ASPLOS ‘17, Xi’an, China.
- Featured in the tutorial, Systemized Program Analyses: A Big Data Perspective on Static Analysis Scalability, ASPLOS ‘17.
- Invited for presentation at SoCal PLS ‘16.
- Invited for poster presentation at PLDI SRC ‘16.
OpenMetadata Community Meeting - 5th June 2024OpenMetadata
The OpenMetadata Community Meeting was held on June 5th, 2024. In this meeting, we discussed about the data quality capabilities that are integrated with the Incident Manager, providing a complete solution to handle your data observability needs. Watch the end-to-end demo of the data quality features.
* How to run your own data quality framework
* What is the performance impact of running data quality frameworks
* How to run the test cases in your own ETL pipelines
* How the Incident Manager is integrated
* Get notified with alerts when test cases fail
Watch the meeting recording here - https://www.youtube.com/watch?v=UbNOje0kf6E
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
WhatsApp offers simple, reliable, and private messaging and calling services for free worldwide. With end-to-end encryption, your personal messages and calls are secure, ensuring only you and the recipient can access them. Enjoy voice and video calls to stay connected with loved ones or colleagues. Express yourself using stickers, GIFs, or by sharing moments on Status. WhatsApp Business enables global customer outreach, facilitating sales growth and relationship building through showcasing products and services. Stay connected effortlessly with group chats for planning outings with friends or staying updated on family conversations.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
1. .5
Xavier Franch
Group of Software and Service Engineering
Universitat Politècnica de Catalunya
Barcelona, Spain
franch@essi.upc.edu
Guenther Ruhe
Software Engineering Decision Support Laboratory
University of Calgary
Calgary, Alberta, Canada
ruhe@ucalgary.ca
2. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 2
3. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 3
5. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 7
6. Context – Software Evolution
ICSE 2016, Austin, TX 8
Continuing Change — an [E-type] system must be continually
adapted or it becomes progressively less satisfactory (Law 1)
Continuing Growth — the functional content of an [E-type]
system must be continually increased to maintain user
satisfaction over its lifetime (Law 6)
Laws of Software Evolution
Manny Lehman (1925 – 2010)
what/when/how to evolve?
Release
Planning
7. The planning onion
ICSE 2016, Austin, TX 9M. Cohn, Agile Estimating and Planning. Prentice Hall PTR, 2006.
8. Software release planning – definition
ICSE 2016, Austin, TX 10
Software release planning – “critical process of deciding which
features are implemented in which releases”
G. Ruhe. Product Release Planning, CRC Press 2010
Release planning – Strategic + operational
Strategic release planning – “selection and assignment of
requirements in sequences of releases such that
important technical and resource constraints are fulfilled”
Operational release planning – “development of the
identified features in a single software release”
Svahnberg et al. A Systematic Review on Strategic Release
Planning Models. IST 52(3), 2010
9. Example: SENERCON
ICSE 2016, Austin, TX 11
• Partner of the SUPERSEDE H2020 project
• Service provider for energy savings based in Berlin with
more than 75.000 users
• After developing more than 20 services, still success is
unpredictable, concluding that:
– the success of a service mostly depends on fulfilling personal
and individual needs of the end-user
– mismatch QoS – QoE The Black Box Problem
10. Example: SENERCON
ICSE 2016, Austin, TX 12
• Main reasons:
– lack of detailed knowledge about QoE
• currently, email + hotline only
– not having a systematic release planning approach in place
• currently, based on expert judgement
• Goal: a cost-effective exchange hub users developers
– contextualized user feedback
– discovery of service usage patterns
– combine feedback with context
• Once this information is known:
– features’ value easier to quantify
– systematic release planning may be put in place
11. What is a feature
ICSE 2016, Austin, TX 13
“A logical unit of behavior specified by a set of functional and
non-functional requirements”
J. Bosch. Design and Use of a Software Architecture. ACM Press 2000
“A distinguishable characteristic of a concept (system, compo-
nent, etc. ) that is relevant to some stakeholder of the concept”
K. Czarnecki, U.W. Eisenecker. Generative Programming: Methods, Tools and
Applications. Addison-Wesley 2013
“A set of logically related requirements that provide a capability
to the user and enable the satisfaction of business objectives”
K. Wiegers, J. Beatty. Software Requirements (3rd ed.), Microsoft Press 2013
12. Typical features
ICSE 2016, Austin, TX 14
• Core functionality of the domain
– prime prerequisite for a company’s business
• Demanded by the market
• Requested by a specific customer
T. Berger et al. What is a Feature? A Qualitative Study of Features in Industrial
Software Product Lines. SPLC 2015
13. Good and bad features
ICSE 2016, Austin, TX 15
Reasons for considering a feature as “good”:
• Customer satisfaction
• Distinct functionality
• Well implemented and error free
What makes a feature “bad”:
• Result of time pressure and rushed development
• Compromises emerging during implementation
• Duplicated and superfluous features
• High volatility
T. Berger et al. What is a Feature? A Qualitative Study of Features in Industrial
Software Product Lines. SPLC 2015
17. Software release planning - Why difficult?
ICSE 2016, Austin, TX 19
Information is
Uncertain
Inconsistent
Incomplete
Fuzzy
Decision space
Large size
High complexity
Dynamically changing
Multiple objectives
Usability
Value
Time-to-market
Frequency of use
Risk
Hard & soft constraints on
Time
Effort
Quality
Resources
18. Main challenges in release planning
• Product management underestimated/not sufficiently established
• Product release planning process immature
• Product release planning not synchronized with other processes
• Lack of systematic re-planning
• Lack of transparency of release decisions
• Lack of definition of planning goals/alignment with business goals
• Lack of stakeholder involvement
• Lack of resource consideration
• More re-active than pro-active planning mode
• Impact of better release content unclear
• Impact (value) of individual features unclear
• Planning for just the next release
ICSE 2016, Austin, TX 20
19. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 21
20. Approaches to Software Release Planning
Two main categories
• manual (“on-the-fly”) approaches
– rely on humans’ ability to negotiate
between conflicting objectives and
constraints
– mainly reported as experience reports
• analytical approaches
– formalize the problem
– apply computational algorithms to
generate best solutions
– mainly reported as scientific technical
papers
ICSE 2016, Austin, TX 22
G. Ruhe, M.O. Saliu. The Art and Science of Software
Release Planning. IEEE Software 22(6), 2005
21. On-the-fly approaches
ICSE 2016, Austin, TX 23
• emphasis on improving the decision process
– make estimates as accurate as possible
– provide stakeholders a voice
• emphasis is in the next release
– planning long term is more difficult
22. Example: a case in Ericsson
V.T. Heikkilä et al. Continuous Release Planning in a Large-
Scale Scrum Development Organization at Ericsson. XP 2013ICSE 2016, Austin, TX 24
• Ericsson node development unit
– traffic management in telecommunication networks
– large systems
– combining hardware and software
• Large projects
– 20 development teams fro Finland and Hungary
– every team had 6-7 members
– following Scrum
• The products
– yearly public releases
– 2 internal versions per release, 2 internal deadlines for
maintenance updates
25. Reported benefits
• Increased flexibility
– feature development schedule not tied to release schedule
– decreased development lead time
• Eliminate waste in the planning process
– early identification of too expensive or unfeasible features
save development resources
• Increased developer motivation
– early involvement of developers in the feature planning
process
ICSE 2016, Austin, TX 27
26. Remaining challenges
• Misalignment with “the old way” of planning
– product manager still asking for long-term feature
development plans
• increasing detail of FCS
• Managing non-feature specific work
– non-feature specific problem reports, system documentation,
external change requests, …
• Low prioritization of system improvement work wrt
implementing new features
– some store points saved for system improvements
ICSE 2016, Austin, TX 28
27. Limitations of on-the-fly approaches
• Informal process
• Informal decisions
• But: > 1.000.000.000.000 possibilities already in case of
20 objects and three periods
ICSE 2016, Austin, TX 29
28. Analytical approaches
F = {f(1), ..., f(N)}
Set of features Set of constraints
X = {x(1), ..., x(N)}
Release plan
x(j) = assigned release
C = {c(1), ..., c(M)}
RP
maximise some utility
or objective function
ICSE 2016, Austin, TX 30
29. Analytical approaches
F = {f(1), ..., f(N)}
Set of features Set of constraints
X = {x(1), ..., x(N)}
Release plan
x(j) = assigned release
C = {c(1), ..., c(M)}
RP
maximise some utility
or objective function
What information
is processed?
Which results are
produced?
How is the plan
computed?
ICSE 2016, Austin, TX 31
30. Example – release planning in agile projects
Approach Iterations Precedences Risk Change mgmt. Planning
[1] Multi Preced, coupling Some Some Heuristic
[2] Multi Preced Yes No Greedy
[3] Single Preced, coupling No Yes Exact
[4] Single Preced No Some Exact
[5] Multi Preced, coupling Yes No Exact
[6] Multi Preced, coupling Yes No Exact
[7] Multi Preced, anchor, coupling Yes Yes Exact
[1] D. Greer, G. Ruhe. Software release planning: an evolutionary and iterative approach. IST 46, 2004
[2] M. Denne, J. Cleland-Huang. Software by Numbers. Prentice Hall, 2004
[3] M.O. Saliu, G. Ruhe. Supporting software release planning decisions for evolving systems. SEW 2005
[4] C. Li et al. An integrated approach for requirement selection and scheduling in software release
planning. REJ 15, 2010
[5] A. Szoke. Conceptual scheduling model and optimized release scheduling for agile environments. IST
53, 2011
[6] G. van Valkenhoef et al. Quantitative release planning in extreme programming. IST 53, 2011
[7] M. Golfarelli, S. Rizzi, E. Turrichia. Multi-sprint planning and smooth replanning: An optimization
model. JSS 86, 2013
31. State of the art
Main source: systematic literature review until 2008
• 24 release planning models found
– 14 original and 10 extensions, mostly from 1998
• Three main groups
– EVOLVE-family + ReleasePlanner tool @ University of Calgary
– SERG @ Lund University
– Center of Organization and Information @ Utrecht University
ICSE 2016, Austin, TX 33
Svahnberg et al. A Systematic Review on Strategic Release
Planning Models. IST 52(3), 2010
32. State of the art
Extension: ongoing non-systematic literature review until
2015 by the GESSI research group at UPC
• snowballing based approach
– forward snowballing from Svahnberg et al.’s SLR C1
– backward snowballing from C1
– focus on selected journals and conferences
– contributions from industry also sought
• Final selection: 16 new methods found in the period
2009-2015
ICSE 2016, Austin, TX 34
33. New methods in a nutshell (sample)
ICSE 2016, Austin, TX 35
NRP for eXtreme Programming dealing with some uncertainty
Multsprint planning in an agile context
Combining a planning algorithm with a scheduling method
Efficient algorithm for NRP in the projects with large sets of
requirements
NRP in large scale agile organizations
Calculate the impact of uncertainty with time constraints in
release planning
Define new releases in agile environments taking into account
previous iterations
Efficient NRP algorithm based on model checking considering
dependencies
Implement a risk-aware NRP algorithm
34. Input: constraints and factors
ICSE 2016, Austin, TX 36
Soft
factorsRisk factors Value factors
Resource consumption factors
Stakeholders’ influence factors
Svahnberg et al.
A Systematic Review
on Strategic Release
Planning Models.
IST, 52(3), 2010
Requirement dependencies
Quality constraints
Budget and cost constraints
Resource constraints
Effort constraints
Time constraints
Hard
constraints
35. Input: constrains and factors (prevalence in 2010)
ICSE 2016, Austin, TX 37
Requirement dependencies (75%)
Quality constraints
(8.3%)
Budget and cost constraints
(29.1%)
Resource constraints
(33.3%)
Effort constraints
(50%)
Time constraints
(16.7%)
Soft
factorsRisk factors
(12.5%)
Value factors
(37.5%)
Resource consumption factors (20.8%)
Stakeholders’ influence factors (29.2%)
28 methods
Hard
constraints
37. Output
• Scope
– one release vs. multiple releases
• Object of planning
– features; user stories; requirements
• Prioritization
– none
– ordinal
– must-have, should-have, could-have
• Time scheduling
• Developer assignment
ICSE 2016, Austin, TX 39
38. Objective function
• Optimization of the value given by the features while
managing the resources and fulfilling all possible
constraints
• How to measure value:
– business value, stakeholder satisfaction, urgency, risk
minimization, technical debt, return on investment, …
• How to measure resources
– personnel, availability
– considering size/complexity of features
• Constraints
– dependencies, time constraints, …
ICSE 2016, Austin, TX 40
39. A lot of computational approaches…
ICSE 2016, Austin, TX 41
Greedy
algorithms
Pareto opti-
mal fronts
Monte-Carlo
simulation
Knapsack
problem
Branch and
bound Backbone
based
algorithms
Graph trans-
formation
AHPClustering
40. Example – greedy solution (1)
• Principle: always add a feature to the solution that
maximizes value while not violating any constraint or
requiring more resources than available
• Greedy algorithms: building a good global solution as
the sequence of local optimum choices at every
moment
ICSE 2016, Austin, TX 42
41. Example – greedy solution (2)
• Input:
– Set of features, F = {f(1), …, f(N)}
– Resource consumption, cost: F Integer
– Estimated values, value: F Integer
– Set of cost capacity for each release:
totalCost: Integer Integer
• Output:
– Release planning, Release: Integer {Integer}, s.t. all sets
are pair-wise disjoints
ICSE 2016, Austin, TX 43
G. Ruhe. Product Release Planning, CRC Press 2010
43. Example – Multi-sprint planning in Scrum (1)
• Given a set S of m sprints and a set U of n user stories,
maximise a solution z for the m sprints
• Goals:
– customer satisfaction
– coupling management
– criticality risk management
• Strategy
– generalized assignment model
M. Golfarelli, S. Rizzi, E. Turrichia. Multi-sprint planning and
smooth replanning: An optimization model. JSS 86, 2013
ICSE 2016, Austin, TX 45
44. Example – Multi-spring planning in Scrum (2)
Example of input:
ICSE 2016, Austin, TX 46
ID Name Deps. and
coupling
Utility Comple-
xity
Criticality
risk
Uncert.
risk
s1 Fee configuration s1->s2 80 5 Low Low
s2 Cash cost computation 0.3 s2+s10 85 2 Medium Medium
s3 Import from DBMS 75 2 Medium Medium
s4 Parameterization logic 30 1 Medium Medium
s5 Amortization mask 60 2 No No
s6 Exchange computation 60 2 Low Medium
s7 Exchange import from SAP s7->s6 60 7 Low Low
s8 Mngmt . control reporting 85 4 Medium Low
s9 Operational reporting 100 10 Low Medium
s10 Scenario management mask 0.3 s2+s10 65 3 Low Low
45. Example – Multi-spring planning in Scrum (3)
• Objective function z:
– uj: utility of story j
– rj
cr: criticality risk of story j
– xij = 1 if story j is included in sprint i
– G: set of coupling groups of stories; Al: a set of coupled
stories
– al: affinity between stories in Al
– yijl: number of stories of Al affine to story j and included in
sprint i
ICSE 2016, Austin, TX 47
46. Example – Multi-spring planning in Scrum (4)
the sum of stories’ complexity
(considering uncertainty risks) fits
into each sprint capacity
each story is planned in exactly one
sprint
each forced story is planned in the
planned sprint
correct consideration of OR- and
AND-dependencies among features
restricting values of affine stories
ICSE 2016, Austin, TX 48
47. Summary: Analytical vs. on-the-fly planning
ICSE 2016, Austin, TX 49
Caracteristics Analytical methods On-the-fly
Time horizon Next release, but applicable more
general
Next release
Objectives Flexible, but typically value-based Vague and not explicitly described
Stakeholder involvement Not directly supported Opportunistic and by communication
Solution method Greedy heuristic, linear
programming, simulation, ..
Intuition and experience-based
Quality of solutions Good on average, but unknown for
specific case
Difficult to judge. The more risky, the
more complex the problem
Feature dependencies Typically not considered Implicitly, hard to consider for more
complex problems
Human resource
constraints
If at all, then just cumulative effort Implicitly, hard to consider for more
complex problems
What-if analysis
(explicit support)
No No
Integrated tool support Limited No
48. Summary
ICSE 2016, Austin, TX 50
• On-the-fly approaches criticised due to the difficulty
of taking into account all knowledge implied by
software release planning
• Conversely, analytical approaches criticised either
because:
– Too simple to be useful
• Lack of information considered
• Over-simplifications (e.g. requirement dependencies)
– Too complex to be adopted
• Learning curve
• Lack of trust in result
49. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 51
50. Release planning – Art or Science?
ICSE 2016, Austin, TX 52
• Art:
Focus on the human
intuition and
communication for
handling tacid
knowledge
• Science:
Emphasis on formalization of
the problem and application of
computational algorithms to
generate best solutions.
51. What’s the problem?
ICSE 2016, Austin, TX 53
“The mere formulation of a problem is far
more essential than its solution, which may be
merely a matter of mathematical or
experimental skills. To raise new questions
(and), new possibilities, to regard old
problems from a new angle, requires creative
imagination and marks real advances in
science.”
(Albert Einstein, 1879-1955)
52. Optimized release planning – How it began
ICSE 2016, Austin, TX 54
EVOLVE: Greer, D. and Ruhe, G., Software Release Planning: An Evolutionary and
Iterative Approach, Information and Software Technology, Vol. 46 (2004), pp. 243-
253.
What constitutes a release plan?
Max{ F(x, α) = (α - 1) F1(x) + α F2(x) subject to 0 ≤ α ≤ 1, x from X}
Stakeholders
Weightings for stakeholders
Scores of stakeholders towards urgency (F1) and value (F2)
X composed of
- effort constraints
- coupling and precedence constraints (between features)
53. Optimized release planning – How it began
ICSE 2016, Austin, TX 55
F1(x) is a penalty function defined for plan x describing the degree of
violation of the monotonicy property between all pairs of features
F2(x) is a benefit function based on feature scores of the stakeholders and the
actual assignment of the feature according to the plan under consideration.
value(n,p) = value_score(n,p)(K – x(n) +1)
54. Empirical analysis
• EVOLVE was initially based on genetic search offered by
Palisade’s RiskOptimizer
• Early industrial feedback (Corel, Siemens)
• Development of our own GA (emphasis on avoiding
premature convergence)
• Empirical studies with 200 to 700 requirements comparing
the GA with running ILOG’s CPLEX
• Better solutions for LP solver in reasonable time
• Known level of optimality
• Development of our own solution method utilizing open
source optimization combined with knapsack-type of
heuristic for B&B
• New approach more flexible and with higher level of
diversification among top solutions.
ICSE 2016, Austin, TX 56
55. EVOLVE II: Three phases
• Phase 1 - Modeling:
– Formal description of the
(changing) real world to make it
suitable for computational
intelligence based solution
techniques
• Phase 2 - Exploration:
– Application of computational
techniques to explore the
solution space, to generate and
evaluate solution alternatives
• Phase 3 - Consolidation:
– Human decision maker evaluates
current solution alternatives
– Match with implicit objectives
and constraints
ICSE 2016, Austin, TX 57
Computational Intelligence
Interation 1 Release 1
Release 2Interation 2
Interation 3 Release 3
Human Intelligence
56. Evolution everywhere
• Evolutionary software development (iterative,
incremental)
• Evolutionary solution algorithms
• Evolutionary problem solving (synergy between art and
science)
ICSE 2016, Austin, TX 58
57. The diversification principle
ICSE 2016, Austin, TX 59
A single solution
to a cognitive
complex problem
is less likely to
reflect the actual
problem when
compared to a
portfolio of
qualified
solutions being
structurally
diversified
Consolidation
58. ICSE 2016, Austin, TX 60
Preparation
1
Planning criteria
weights
2
Pre-selection of
features
3
Prioritization of features
4
Voice-of-the
stakeholder analysis
5
Technology constraints
7
Resource estimation
6
Optimization
8
Quality and
resource analysis
9
Excitement analysis
10
Stakeholder
evaluation of plans
12
What-if-analysis
11
Final plan decision
13
dependency
between steps
mandatory step
optional step
set of logically
linked steps
feedback link
Stakeholder-centric release planning –
Method EVOLVE II
59. Criteria for feature selection
• Customer satisfaction
• Customer dissatisfaction
• Risk of implementation
• Risk of acceptance
• Financial value
• Cost
• Time to market
• Volatility
• Frequency of use
• Ease of use
ICSE 2016, Austin, TX 61
60. Feature dependencies
• For given features
A, B, and C, we
distinguish eight
types of
dependencies:
ICSE 2016, Austin, TX 62
62. Maximization of stakeholder feature points
ICSE 2016, Austin, TX 64
Stakeholder
weight
Score(n,q)
Criteria
weight
SCORE(n)
Releases
weight
sfp(n,x)
TSFP(x)
Features
score(n,p,q)
Plan x
63. Resource constraints
• Resource class 1: A resource type r belongs to class 1 if
the feature related consumption of the resource is
limited to exactly the release in which the feature if
offered. Resources of this class are called local based
on its spending mode.
ICSE 2016, Austin, TX 65
Consumption(k,r,x) = ∑n: x(n)=k consumption(n,r)
≤ Capacity(k,r)
64. Resource constraints
• Resource class 2: A resource type r belongs to class 2 if
the feature related consumption of the resource can be
distributed across different release periods. Resources
of this class are called global based on its spending
mode.
ICSE 2016, Austin, TX 66
∑ n=1..N wx (n,k,r) consumption(n,r) ≤
∑ Capacity(k,r) for all releases k = 1…K
0 ≤ wx (n,k,r) ≤ 1 for all n,k,r
∑ k = 1 .. K wx (n,k,r) = 1 for all n,r
65. Comparison of EVOLVE II with other methods
ICSE 2016, Austin, TX 67
Method
Characteristics EVOLVE II on-the-fly planning [van den Akker et al. ‘08]
Time horizon Flexible Next release Next release
Objectives Flexible in the number and
type of criteria
Vague and not explicitly
described
Maximize financial value
function
Stakeholder involvement Strongly supported with
explicitly assigned
individualized tasks at the
different stages
Opportunistic and by
communication
Not directly supported
Solution method Specialized integer
programming with additional
heuristics
Intuition and experience-based Integer linear programming
(ILP)
Quality of solutions Five near optimal alternative
solutions with known level of
optimality
Difficult to judge. The more
risky, the more complex the
problem
Near-optimal solutions based
on ILOG
Feature dependencies Precedence and coupling Implicitly, hard to consider for
more complex problems
Precedence,
coupling, either or
dependencies
Human resource constraints number, type and granularity
of the resources
Implicitly, hard to consider for
more complex problems
Yes, including staffing of teams
What-if analysis
(explicit support)
Yes No Yes
Integrated tool support ReleasePlanner 2.0 No Prototype based on usage of
ILOG
66. EVOLVE II tool support - ReleasePlanner
ICSE 2016, Austin, TX 68
68. Use cases
1. Project definition: stakeholders, criteria, features, resources,
estimates, capacities, number of releases, permissions
2. Feature prioritization
3. Most controversial features
4. Alternative plan generation
5. Feature dependencies
6. Excitement analysis for a given plan
7. Customization of plans
8. Comparison between two selected plans
9. JIRA: Import of issues and subsequent plan generation
10. Change of data in JIRA and synchronization
11. Innovation planning where stakeholder represent competitors
12. Service portfolio planning
13. When to release planning
14. Feedback-driven planning
15. Planning functional versus quality requirements
ICSE 2016, Austin, TX 70
69. Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
• PART IV. CONCLUSIONS
ICSE 2016, Austin, TX 71
71. Open innovation
• An (open) approach for integration of internal and
external ideas and paths to market that merges
distributed knowledge and ideas into production
processes.
ICSE 2016, Austin, TX 73
72. Release Planning – Information needs
ICSE 2016, Austin, TX 74
Information needs
Type of release planning problem
Features
Featuredependencies
Featurevalue
Stakeholder
Stakeholderopinionand
priorities
Releasereadiness
Markettrends
Resourceconsumptions
andconstraints
What to release × × × × × × ×
Theme based × × × × × × ×
When to release × × × × × × ×
Consideration of quality requirements × × × × × × ×
Operational release planning × × ×
Consideration of technical debt × × × ×
Multiple products × × × × × × ×
73. Analytic open innovation
• Open innovation with emphasis on analytics
(processes, tools, knowledge, techniques, decisions).
ICSE 2016, Austin, TX 75
74. How much planning is enough?
ICSE 2016, Austin, TX 76
Perfection of information 100%
Valueand
costofadditionalinformation
(Harrison 1987)
Benefit
Cost
Cost-benefit
ROI the better the more often investments are used
75. Pro’s of investment
• Pro-active evaluation of impact of decisions
• Support to find the most promising decision
alternatives
• Transparency
• Understandability
• Reducing the impact of
human bias
• Reducing the risk of failure
• Increasing the chance of
success
77ICSE 2016, Austin, TX
76. Con’s from investment
• Additional effort on decision-making
• Additional effort on information retrieval
• Effort to become familiar with some support tool(s)
• Unavoidable uncertainty (depending on scope)
78ICSE 2016, Austin, TX
78. Summary
• Basic assumption: The more qualified processes and
support is provided, the better the chance to find an
appropriate decision.
• Benefit of a mature release planning process:
– Better customer satisfaction
– Higher competitiveness of
products
– Transparency of decisions
– Ability to adjust to change
– Alignment to business
objectives
– Higher predictability of
results
80ICSE 2016, Austin, TX
79. Acknowledgements
• This work has been partially funded by the SUPERSEDE
H2020 project (2012-2015) under contract nb. 644018
• The first presenter wants to thank D. Ameller and C.
Farré at UPC for their work in the topic of the tutorial
• The second presenter acknowledges the support
provided by NSERC and the collaboration with Maleknaz
Nayebi on this topic.
ICSE 2016, Austin, TX 81
80. .5
Xavier Franch
Group of Software and Service Engineering
Universitat Politècnica de Catalunya
Barcelona, Spain
franch@essi.upc.edu
Guenther Ruhe
Software Engineering Decision Support Laboratory
University of Calgary
Calgary, Alberta, Canada
ruhe@ucalgary.ca