The goal of being able to build quality in software products from the get-go is something that many organizations are trying to achieve. However, the very definition of software quality is somewhat elusive which makes it difficult to agree upon the perceived level of quality in software products. Moreover, working with legacy systems poses its own set of challenges as uncertainty of preserving overall quality in the legacy product seems to be an everyday struggle for many teams.
This talk builds on a multi-perspective definition suggested by Gojko Adzic in his blogpost “Redefining Software Quality” some years ago. For each perspective a series of well-defined questions will be presented that help teams challenge their own assumptions about quality in the end-product.
The talk is based on practical applications of Gojko’s definition as embraced by the teams working on legacy enterprise software in the healthcare domain.
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
Building Quality in Legacy Systems - The Art of Asking Questions, JavaZone VR 2020
1.
2.
3.
4. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Mufrid Krilic
Senior Software Developer/Coach
DIPS AS, Norway
@mufridk
Building Quality In Legacy Systems – The Art of Asking Questions
Her kan du legge inn
bilde. Du finner
figurer her:
Link
6. Gojko Adzic - Using Maslow as an Analogy for Defining Software Quality
Blogpost:
• «Redefining Software Quality»
• https://gojko.net/2012/05/08/redefining-software-quality/
8. Maslow – Safety Needs
• Quality methods:
• Performance testing
• Risk analysis
• Architecture and design
patterns
Roles to focus on:
• End-users
• People working with information security
11. Maslow – Esteem Needs
• Quality methods:
• Continuous delivery
• DevOps
• Correct metrics
• Production environment
measurements
Roles to focus on:
• End-users, Management
12. Maslow – Self-actualization Needs
• Quality methods:
• Impact Mapping
• Correct metrics
• What impact did the software
product make?
• Did we make or save money?
Roles to focus on:
• Decision makers
• Broader user community
• Public relations
13. Good enough – how to know where to invest?
The more you invest in quality
on this level the better
Focus on good enough
14. How to apply this when working with legacy systems?
The Art of Asking Questions
15. Different perspectives in the legacy system
Ask questions related to
– Delivery process
– Conditions of acceptance
– Code and product maintainability
– Security and performance
– Domain-specific context in existing operational environments
Questions should be asked before or during the development process, not after
16. Delivery process related questions
Any manual steps in the delivery process?
Compatibility with previously installed versions in production
– Can multiple versions of the product exist side by side?
Documentation
Deployable?
17. Conditions of Acceptance
Automatic and explorative testing
Testing integration points with other parts of the system
– How to avoid introducing undesirable behavior?
– Learn from experiences of the past
– Talk to people in your organization
Functionally ok?
18. Case: Patient Admission Letters – Context Map
Admission Letter
Templates
ReferralAppointments
Surgery
Send
Letter to
Patient
Patient Information Next of Kin Send Message
to GP
Type of Integration:
• Which team
• What type of relation with the team
Health Record
19. Code and product maintainability related questions
Diagrams and maps
– How to document integrations with other parts of the application?
Logging and profiling
– Just enough to be able to monitor usage in production
Functionally ok?
20. Security and performance related questions
Performance testing, memory footprint, authentication, authorization….
Code analysis for discovering patterns that could lead to bugs in production
– Asynchronous communication patterns
– Multithreading issues
Concurrency control
– Could new functionality introduce concurrency conflicts elsewhere in the system?
Performant, secure?
21. Domain-specific context in existing operational environments
How is the legacy system used today?
– To what extent will users’ behavior change with new functionality?
Examples from healthcare: Essential functionality customers takes for granted
Usable? Useful?
The most challenging
questions to address are
domain-specific
24. Summary: Mapping of different perspectives to the software quality pyramid
Conditions of acceptance
Delivery process
Code and product maintainability
Security and performance
Domain-specific context in existing
operational environments
26. Application of this Approach
• Start with a set of questions
that work for you
• Engage with your users
• Every piece of work
is bigger than
initially assumed
27. It boils down to this….
• Strengthen the
team’s ability in
decision-making
• Relentless learning
Deployability with Functionality, Performance with Security, Usability
En multi-perspektiv definisjon krever en bred tilnærming
– Behov for å vite at man har dekt alle perspektiver
Finne rollene som har behov for dokumentasjon og under hvilke aktiviteter i forretningsprosessen oppstår behovet
Tradisjonelt har legacy systemer etterlatt store mengder med dokumentasjon gjennom årene- Vil mer dokumentasjon hjelpe? Små release notes vs. omfattende brukerdokumentasjon
Forhold til IT-avdelinger hos kunden
Integration points and backwards compatibility
Hard to find sweet spot for logging
Build experience to help you recognize potential issues up-front, such as multi-user collaboration, or a single user crossing subdomain boundaries