Evaluation of software development process the case of fapi of fpt software = Đánh giá quy trình phát triển phần mềm dự án Fapi của công ty Fpt-software
Contexte
Rôle des logiciels
Le logiciel est partout Dans les années 1980, il est passé des mainframes aux
Software is now embedded in everyday products like home appliances, smartphones, and vehicles, playing crucial roles in operating rooms, aircraft navigation, and factory operations It enhances our living environments by managing temperature, lighting, and security, and future innovations may allow smart clothing to adapt to our individual needs upon entering a room The economic significance of software is undeniable, as is society's reliance on it, highlighted by past fears such as the Y2K bug, which underscored the potential for catastrophic system failures Today, the role of software is more critical than ever, with increasing complexity and functionality driving the demand for high-quality solutions As software becomes a core strategic technology, the pressure for faster production timelines has intensified, often leading to quality challenges.
Stratégies de développement de logiciels
The software development landscape is undergoing rapid and significant changes, not only in technical and methodological aspects but also in business strategies In the 1980s, software development was primarily an internal activity, with no commercial off-the-shelf (COTS) software available, and open-source development methods were virtually non-existent Today, these evolving strategies, particularly open-source approaches, play a crucial role in enhancing software development practices.
Due to recent changes, the company aims to enhance its software development methods and strengthen its competitive position A notable trend in software development is the emergence of virtual organizations, where partners are sourced separately for each project Currently, software development is often a multi-site operation, involving either geographically dispersed teams within the same organization or collaboration with other companies through subcontracting agreements According to Nasscom (2000), 185 of the top 500 software development firms have outsourced their software development to India, with an impressive annual growth rate of 53%.
Modèles de processus de développement logiciel
The software development process model has evolved significantly since Royce introduced the waterfall model in 1970, which emphasizes a sequential progression through defined phases, activities, and outcomes Over the years, various models have emerged, including iterative, incremental, evolutionary, prototyping, spiral, and the V-model, all aiming to address the limitations of existing approaches and tackle new challenges in software development The creation of new software development models continues, with agile methodologies gaining prominence Among them, Extreme Programming stands out as a widely recognized agile method, alongside other lightweight development approaches such as Scrum and Crystal These agile methods are particularly favored in scenarios where rapid market delivery is crucial, enabling the swift and incremental development of applications.
La quête d’amélioration
The primary aim of software improvement is to enhance the quality of development Additionally, objectives may include shortening execution times, reducing costs, increasing profitability, or strengthening market position This process may also require demonstrating development maturity, which could necessitate modifications to the software development process.
Defining quality is challenging as it is subjective and perspective-based The ISO 9000 standard describes quality as the degree to which a set of inherent characteristics of a product meets requirements, which are understood as explicit, generally implicit, or mandatory needs or expectations Quality characteristics can be differentiating, inherent or attributable, qualitative or quantitative, and categorized in various ways Ishikawa (1985) emphasizes quality from the customer's viewpoint, aiming to satisfy customer requirements, while Juran (1999) defines customer-based quality as being fit for its purpose It is widely recognized that competitiveness largely hinges on the quality of products or services, as ultimately evaluated by customers.
In a broader interpretation of quality, Ishikawa identified various dimensions, including work quality, service quality, information quality, process quality, personnel quality (encompassing workers, engineers, managers, and executives), system quality, and company quality Consequently, quality cannot be added to a product at a later stage, whether in manufacturing or software development, as emphasized by Humphrey (1989).
Software quality is generally measured through various attributes, including reliability, usability, maintainability, portability, scalability, and testability Some of these quality attributes, like reliability and usability, are more apparent to customers, while others, such as maintainability, are crucial for software development This list can be expanded to include additional quality standards, such as security and time-to-market considerations.
— Le mouvement de la qualité
Le mouvement pour la qualité a commencé au Japon dès la fin des années 1940.
In 1949, the Japanese Federation of Scientists and Engineers established a research group focused on quality control and initiated a nationwide quality training program By 1982, W Edwards Deming, a key figure in Japan's quality movement, introduced the Plan-Do-Check-Act (PDCA) management model This PDCA cycle, also referred to as the control circle, was subsequently adapted for software development.
The quality movement in software development emerged relatively late, gaining traction in the mid-1980s when practitioners and researchers began to focus on developing Software Process Improvement (SPI) models and methods This ongoing evolution has led to the creation of various new and enhanced models, often seen as competitors The introduction of the Software Capability Maturity Model (CMM), later known as SW-CMM, sparked extensive discussions about software development process quality Subsequently, several maturity models with similar principles, such as Bootstrap and ISO 15504, have been published In addition to these process quality models, numerous standards exist, including the ISO 9000 series and IEEE standards, along with application-specific software quality standards Furthermore, other improvement tools like ISO 9000 certification, the European Quality Award, and the Malcolm Baldrige Award are now utilized by various software development organizations.
Contexte de recherche
Problématique de la recherche
Evaluating the software development process at FAPI is a challenging task due to the inherent complexity and human-centric nature of software engineering Unlike other engineering fields, software engineering involves characteristics that are difficult to plan or control It is an intellectual and sociological activity conducted in a learning environment, making planning and management particularly difficult As noted by Reel (1999), the software system is extremely complex, and many agree that mastering this complexity is a fundamental challenge in computing Software developers, who often face intricate problems, are typically highly intelligent individuals, which further complicates management strategies This complexity is compounded for software experts, as it can significantly impact their self-esteem.
In the realm of embedded systems, software development efforts frequently account for over half of the total system development Successfully transforming core engineering activities is challenging; it requires shifts in attitudes, models, methods, and tools related to software development, work procedures, and project management.
Continuous changes in business goals, strategies, and software development, alongside stricter quality objectives and time-to-market (TTM) requirements, necessitate adjustments in business methods By enhancing the software process, the company aims to boost its competitiveness and productivity.
But de notre projet
To address the increasing number of bugs and requests, as well as the high volume of open cases and prolonged implementation times for new features, it is essential to identify the root cause of these issues During our project timeframe, we aim to assess the development process to uncover the underlying problems and provide suitable recommendations for improvement.
Approche préconisée
To achieve our goal, we focus on evaluating the development process by identifying missing or inadequate aspects This evaluation will be based on the recommended practices of the Software Capability Maturity Model Integration (CMMI), although other models such as the Software Maintenance Maturity Model (S3M) or the ITIL (Information Technology Infrastructure Library) framework may also be utilized The process evaluation is consolidated into a method known as the Process Evaluation Method (PEM), where the source of the evaluation model is determined based on the requirements and objectives during the assessment of events.
Objectifs du projet
Selon l’équipe de développement et de maintenance, les objectifs du projet sont les suivants :
— Améliorer la qualité des logiciels en réduisant les taux d’anomalies de 10% au cours des 24 prochains mois ;
— Réussir à ce que chaque employé puisse travailler que sur un projet à la fois pour améliorer l’efficacité du travail ;
Pour atteindre ces objectifs, nous avons défini les objectifs de ce travail à réaliser durant le stage :
Comprendre et identifier les forces et les faiblesses du processus de dé- veloppement :
— En évaluant les processus logiciels en utilisant les meilleures pratiques CMMI et S3M ;
N.B : nous nous limitons à une evaluation qualitative mais non quantitative.
Portée de la recherche
La norme ISO dộfinit en outre un produit comme ô le rộsultat d’un ensemble d’activitộs interdộpendantes qui transforment les intrants en extrants ằ L’ISO
ISO 15504 expands the definition of the software process to encompass the set of processes utilized by an organization or project for planning, managing, executing, monitoring, controlling, and improving software-related activities Additionally, it defines process improvement as the actions taken to modify an organization's processes to better meet business needs and achieve objectives more effectively.
This research focuses on evaluating processes within the context of software development While the specific methods and technologies of software development are not included in the scope of this study, the findings and recommendations derived from the research are incorporated.
Nature de la recherche
According to qualitative research by the OECD, since 1966, research and development can be categorized into fundamental research, applied research, and development Fundamental research enhances scientific knowledge and seeks knowledge for its own sake In contrast, applied research aims to increase knowledge with the overarching goal of implementing the results of fundamental research and discovering new knowledge that can be applied immediately Based on these definitions, this study falls under the category of applied research.
The aim of this constructive research is to assess the software development process through established standards to enhance the efficiency of FAPI The research strategy involves gathering relevant knowledge and utilizing it for the development and evaluation of the FAPI software.
Structure de la mémoire
Cette mémoire porte sur l’évaluation du processus de développement logiciel : le cas de FAPI de FPT Software La structure de cette mémoire est présentée comme suit :
— Le chapitre 1 présente le contexte de cette recherche et décrit le cadre de recherche.
— Le chapitre 2 décrit l’état de l’art, c’est-à-dire quelques extraits de la littéra- ture décrivant comment d’autres personnes ou organisations ont pu réaliser des travaux similaires.
— Sur la base de l’expérience décrite par d’autres, nous avons établi notre mé- thode de travail au chapitre 3, qui comprend l’évaluation.
— Au chapitre 4, nous avons analysé et réfléchi sur nos résultats d’évaluation, y compris les avantages et les points qui doivent être améliorés, ainsi que les conséquences associées.
— Au chapitre 5, nous proposons une série de suggestions qui peuvent aider FAPI à réaliser des améliorations spécifiques après la mise en œuvre.
— Nous terminons par une conclusion dans laquelle nous faisons un retour sur le but et les objectifs de notre projet. de la variance et processuelles
Chapitre 2 État de l’art sur les meilleures pra- tiques de développement de logiciel et leur évaluation.
The intense competition in today's market, particularly in software and related sectors, compels organizations to deliver high-quality products at the lowest possible cost and within tight timelines This necessitates a continuous improvement of the software process, which must first be clearly defined and actively utilized by the organization Importantly, the effectiveness of a software process hinges on its proximity to the individuals responsible for its implementation A company-wide software process model can only be successful if it is adaptable to the specific needs of the project team using it Ideally, teams should develop a process that aligns with their unique requirements while also addressing broader organizational goals, or they may create their own tailored processes that cater to individual needs and the larger organizational context.
Modèles des meilleures pratiques en développement de logiciel
Capability Maturity Model Integration (CMMI)
The CMMI model is a collection of best practices designed to assist organizations in enhancing their processes Developed by the Software Engineering Institute (SEI) at Carnegie Mellon University for the U.S Department of Defense (DoD), CMMI evaluates a company's ability to deliver quality products This model encompasses best practices across 22 process areas, which can be categorized into two representations.
— Représentation continue : Dans cette représentation, 22 domaines de pro- cessus sont divisés en quatre catégories Chaque domaine de processus est associộ à des niveaux de compộtence allant de ô 0 ằ à ô 3 ằ (0-incomplet ;
The evaluation process generates a "profile" of the software process capabilities based on three fundamental levels: Basic, Disciplined, and Tailored This allows the organization to identify areas for improvement by focusing on the process domain with the lowest capability level, aligning enhancements with its specific needs.
The tiered representation defines an overall maturity level instead of individual levels for each process area Each maturity level corresponds to a subset of process domains and practices that the organization must meet at the target level This process evaluation based on the tiered representation yields the overall maturity level of the software process To enhance the maturity of its software process, the organization can focus on the process domain at the target level that has not yet been achieved.
Dans représentation étagée, les domaines de processus sont regroupés en cinq niveaux de maturité Les domaines de processus rattachés à un niveau de maturité
M ne peuvent être stabilisés et efficaces que si les domaines de processus des niveaux inférieurs (< M) sont déjà stabilisés et efficaces Les cinq niveaux sont :
1 Initial : Le niveau auquel le résultat final est imprévisible (budget, calen- drier, portée, qualité) A ce niveau, le succès dépend plus du titulaire et de son engagement que de l’application disciplinée des bonnes pratiques L’en- vironnement de développement est instable Pas de gestion de processus - il est facile d’être affecté par les crises Manque d’évaluation de l’efficacité et de la performance Le document n’existe pas ou est peu développé.
2 Discipliné : définit la gestion de projet de base pour assurer le cỏt, le délai et la fonctionnalité du projet de surveillance La discipline pour ce processus est en place Le processus du projet est discipliné et ses caractéristiques sont :
— Les activités sont planifiées et exécutées conformément à une politique d’organisation.
— Pas de compromis sur la qualité.
— Les rôles, responsabilités et parties prenantes sont définis et connus.
— Les parties prenantes disposent des compétences et des ressources adé- quates pour réaliser les produits.
— La mise en œuvre du processus fait l’objet d’un suivi, de vérifications et d’ajustements si nécessaire.
3 Défini : A ce niveau, l’organisation dispose d’un ensemble de processus nor- malisés qui sont ajustés en fonction du projet selon le contexte du client et dont les règles sont fixées par l’organisation Le processus normalisé est déve- loppé, maintenu, soutenu et contrôlé par l’équipe responsable du processus. Chaque projet met à profit son expérience et renforce le capital collectif Le cycle de vie et le processus d’ingénierie sont également standardisés par type de projet à ce niveau Le niveau 3 établit un cycle d’amélioration : Utiliser l’expérience, les avantages et les difficultés rencontrés dans le processus de développement pour améliorer le développement futur.
4 Gestion quantitative : A ce niveau, le domaine de processus est sous contrôle statistique (suivi d’indicateurs quantitatifs et mesures correctives en cas d’écarts) Si nécessaire, éliminez la cause première de la variation Les mé- thodes de maợtrise des processus statistiques mises en œuvre au niveau 4 peuvent axer les actions d’amélioration sur les pratiques les plus utiles de ces actions Au niveau du projet, ils peuvent identifier les activités qui n’at- teignent pas les résultats attendus et prendre des mesures.
5 Optimisation : À ce niveau, l’organisation est dans une boucle permanente d’optimisation des processus et de la technologie (réduction des causes cou- rantes de variation), et l’optimisation est basée sur une analyse cỏt/bénéfice. Une analyse causale statistique régulière permet ces améliorations.
Permanent optimization loops are defined starting at level 3 and, at level 5, they utilize statistical methods focusing on causal analysis of events This analysis yields insights for the optimization process By minimizing time spent on event analysis, they provide less information overall.
CMMI will serve as the primary model for our project, and we will assess FAPI's software process based on this framework for improvement Our approach will utilize a staged representation, focusing on Level 2 while incorporating relevant process areas from Level 3.
Figure 2.1.1 – Les niveaux de maturité de CMMIRef :https ://slideplayer.fr/slide/9385778/
Le modèle Deming
The original Shewhart cycle, later known as the Deming cycle or PDCA, was the first model to emphasize the importance of improving action methods and continuity Additionally, the data involved in the planning and analysis phase played a crucial role Ishikawa (1985) redefined the Deming cycle into six categories, naming it the control circle within the framework of Total Quality Control (TQC) This model highlights the significance of establishing policies before setting improvement objectives Specific and intentionally stated goals must be based on the problems the organization needs to address, and the data used to monitor the achievement of these objectives should also be clearly defined.
The Control Circle, as illustrated in Figure 2.1.2, emphasizes the significance of scientific methods and rational approaches in achieving quality characteristics through data analysis and statistical evaluation The Ishikawa diagram, or fishbone diagram, is a valuable tool for identifying causal factors affecting desired outcomes It highlights the necessity of incorporating insights from individuals familiar with the relevant processes and fostering an open atmosphere during analysis sessions Opinions must be validated against available data to ensure consensus on conclusions, which is crucial for standardized processes While standardization is essential for success, excessive regulation can be detrimental Therefore, it is vital that employees and engineers understand the detailed norms and regulations, as mere distribution may lead to misunderstanding Ishikawa (1985) asserts that implementation becomes straightforward when Total Quality Control (TQC) principles are followed, with no specific guidelines needed The process involves checking if all causal factors are controlled and confirming that the desired effects are achieved Managers play a critical role in verification, providing feedback to workers based on outcomes Finally, appropriate measures are planned to address any deviations from the desired effects by analyzing causal factors.
Although the Deming circle and the TQC model were originally developed for the manufacturing industry, their improvement approach and philosophy have also been adapted to software engineering.
Software Maintenance Maturity Model (S3M)
The S3M framework is an evolutionary model designed to initiate and guide continuous improvement programs specifically for software maintenance While it does not aim to solve all software issues, it serves as a tailored tool to enhance software maintenance practices Developed by Alain April and validated with the research collaborators of Dr Abran, the S3M model draws inspiration from the exploratory model created by Mohammed Zitouni under Dr Abran's supervision.
The S3M model architecture is grounded in the concept of a defined pathway These pathways consist of interconnected practices that span multiple levels within the model's framework.
Le concept d’aspects est introduit pour créer des groupes le long de l’itiné- raire , par exemple : l’ingénierie du changement doit prendre en compte de des donnộes ằ.
Figure 2.1.3 – Architecture du modèle S3M Ref : https ://www.tandfonline.com/doi/abs/10.1080/0144929X.2022.2032348 ? journalCode=tbit20
The S3M model is divided into four key process domains: process management, project management, engineering, and support This structure is influenced by the CMMI framework to ensure consistency between the two models.
The S3M maturity model is grounded in a practical method that is easily recognizable by all personnel involved in software maintenance Defined by April and Abran, the maturity level of the S3M model is illustrated in Figure 2.1.5.
Figure 2.1.4 – Domaines et secteurs du modèle S3M
To enhance software maintenance activities, we do not apply this model in our projects as we restrict our focus to development projects However, the S3M model remains dedicated to the evolution of the FAPI.
Figure 2.1.5 – Domaines et secteurs du modèle S3M
Ref : https ://www.researchgate.net/ figure/Domains-and-key-process-areas-of-software-maintenance_fig4_221569924
ITIL
The ITIL framework encompasses best practices for IT service management, providing a comprehensive approach to managing IT services from start to finish It outlines a structured methodology through five key phases: strategy, design, transition, operation, and continual improvement Additionally, ITIL aligns with ISO 20000 standards, which certify the effectiveness of IT service processes.
ITIL guides were developed in England in the late 1980s and published by the Office of Government Commerce (OGC) within the British Department of Trade ITIL serves as the foundation for the ISO 20000 standard.
In February 2019, AXELOS, the British organization responsible for managing the ITIL best practices framework, announced the release of ITIL version 4 This comprehensive overhaul emphasizes the value chain supported by principles and practices rather than a process-based lifecycle The new edition of the framework addresses significant technological and methodological trends in recent years, including the development of artificial intelligence, the adoption of cloud computing, and agile approaches.
Un composant clộ du nouveau rộfộrentiel est la chaợne de valeur du service (SVS).
This concept illustrates how the components and activities within an organization collaborate to generate value for the organization itself, its customers, and all stakeholders involved.
Les approches agiles
Agile methods are typically categorized under internal development standards, specifically in the software development life cycle It is widely recognized that adopting agile methodologies provides a competitive advantage for organizations According to Bustard et al (2013), optimal software engineering involves creating the right product through the right process, ensuring overall satisfaction for all stakeholders Many companies have made significant strides towards this goal by implementing agile approaches in their software development Therefore, it is essential to evaluate agility to improve the quality of services and processes within software departments.
Agility is a work philosophy grounded in specific values and principles Agile methods and approaches align with these core values, offering methodologies that support self-organized teams (Boisvert and Trudel, 2011).
Les valeurs et les principes de l’agilité ont été définis en 2001 par un groupe de
Seventeen software development experts aimed to discover an improved approach for creating software that delivers value to clients while minimizing timeframes Their insights culminated in the Agile Manifesto, which outlines four core values and twelve guiding principles.
Figure 2.1.6 – Les 4 valeurs du Manifeste Agile (Agile Alliance, 2001)
Ref : https ://www.atlassian.com/fr/agile
Among the various agile methodologies, the most commonly utilized by small teams are Scrum, Extreme Programming (XP), and Kanban, as highlighted in the 13th Annual State of Agile Report by VersionOne (2019).
Scrum is an empirical framework for agile project management that delivers high-value increments to clients iteratively It relies on self-organizing teams and a client representative known as the Product Owner, who provides the team with a prioritized list of desired features based on their value to the client This methodology was first introduced by Ken Schwaber at the OOPSLA conference in 1995.
Scrum is perfect for projects where the client is uncertain about the features to be developed The tasks to be completed are listed in the Product Backlog The project is executed in iterations, known as Sprints, which typically last between two to four weeks.
Scrum defines three key roles: the Scrum Master, the Product Owner, and the development team At the start of each iteration, a Sprint Planning meeting is held where the Product Owner presents the prioritized items from the product backlog, and the Scrum team selects tasks to be completed in the upcoming Sprint These tasks are then moved from the Product Backlog to the Sprint Backlog Each day during the Sprint, the team conducts a brief synchronization meeting known as the Daily Scrum At the end of each Sprint, the team showcases the completed functionality in a Sprint Review meeting.
According to Wikipedia, the Kanban method is a visual process management system that specifies what to produce, when to produce it, and in what quantity This approach is directly inspired by Toyota's production system and Lean methodologies It emphasizes continuous improvement and aims to eliminate waste.
The Kanban method is the least restrictive among agile methodologies, as it does not impose specific roles such as a product owner or Scrum Master It also does not mandate meetings like daily stand-ups or retrospectives, nor does it require the formation of cross-functional teams, allowing for flexibility in specialist participation.
Le tableau ci-dessous présente les principales différences entre Scrum et Kan- ban selon le site Atlassian.
Figure 2.1.7 – Principales différences entre Scrum et Kanban
Ref : https ://www.atlassian.com/fr/agile/kanban/kanban-vs-scrum
According to agilealliance.org, Extreme Programming (XP) is an agile software development framework focused on delivering higher quality software It is recognized as the most technically oriented among agile frameworks, particularly regarding engineering practices Officially introduced in October 1999 with Kent Beck's book "Extreme Programming Explained," XP is designed to enhance software development processes Don Wells, on extremeprogramming.org, outlines the contexts in which XP is most suitable for implementation.
1 Exigences logicielles en évolution dynamique ;
2 Risques causés par les projets à temps fixe utilisant les nouvelles techno- logies ;
3 Petite équipe de développement étendue colocalisée ;
4 La technologie utilisée permet des tests unitaires et fonctionnels automa- tisés.
La figure ci-dessous montre une comparaison des trois méthodes selon leur niveau de rigueur.
Figure 2.1.8 – Comparaison des méthodes agiles : XP, Scrum et Kanban (Tiré de Dassonville et Al(2019)) [4]
Ref : Benzaki C Norceide M Dassonville A Évaluation de l’agilité à la Division des ressources informationnelles de la Ville du Bonheur UQAM, 2019.
Évaluation des processus logiciels et des logiciels
ISO 15504 pour évaluer le processus logiciel
ISO 15504, ộgalement connue sous le nom de SPICE, est un ô cadre d’ộvaluation des processus ằ dộveloppộ par le sous-comitộ technique conjoint de l’ISO et de la CEI.
ISO 15504, originally derived from the ISO 12207 lifecycle standard, incorporates concepts from various maturity models, including Bootstrap, Trillium, and the Software Capability Maturity Model (SW-CMM) The standard consists of ten parts, with parts 1 to 5 being normative and parts 6 to 10 focusing on enhancements to improve the usability and adaptability of process capability concepts across new process domains and industries.
The evaluation of processes is founded on a two-dimensional model that encompasses both process dimensions and capability dimensions The process dimension is informed by an external process reference model, which delineates a set of processes characterized by process objective statements and outcomes Meanwhile, the capability dimension features a measurement framework that includes six levels of process capability along with their associated process attributes.
Les six niveaux de capacité de processus sont les suivants :
Les neuf attributs des processus sont les suivants :
3 Gestion des produits de travail ;
Figure 2.2.1 – Structure de la norme ISO 15504 Ref : https ://www.iso.org/fr/standard
Le résultat de l’évaluation comprend un ensemble d’évaluations d’attributs de processus pour chaque processus d’ộvaluation, appelộ aperỗu du processus, et peut
Figure 2.2.2 – Modèle d’évaluation bidimensionnel Ref : https ://www.plays-in-business.com/isoiec-15504-spice/ attributs de processus est mesurée dans une plage de quatre valeurs :
The maturity level is determined by measuring process attributes, where achieving a specific level requires all attributes at that level to be realized to a certain extent, and all attributes of subsequent levels to be fulfilled In our project, we aim not to evaluate these process attributes but rather to assess the overall advantages and disadvantages of the FAPI process Additionally, since this process evaluation is conducted by a single individual, challenges arise from a limited evaluation team and the relatively small number of projects, making it difficult to reach a consensus on the realization score of the attributes Furthermore, given that the ISO/IEC 15504 standard is universal, we opted for the PEM method to rely on a more practical implementation description.
Méthode PEM pour évaluer le processus et le logiciel
PEM is an evaluation method that integrates a qualitative assessment based on CMMI to enhance an organization's software processes, along with a quantitative approach It is also grounded in the ISO/IEC 14598-5 standard, which facilitates the measurement of various quality attributes of the software produced through the evaluation process.
The PEM is ideal for small organizations or projects, allowing one or two evaluators to complete the assessment in under a week and deliver insights on both the software process and the software itself.
La PEM comporte sept étapes Les six premières sont tirées de l’ISO/CEI 14598-
The seventh step is established as a value-added phase for the evaluation body, in accordance with ISO/IEC 15504-5 Each step is elaborated in detail within the methodology, akin to the use case description For every step, there is a concise overview, outlining the purpose, contributions, prerequisites for execution, normal activity flow, alternative flow (if applicable), verification activity checklist, outputs, and post-completion conditions and actions to be taken.
1 Analyser les exigences d’évaluation : Décrire les besoins d’évaluation et l’en- vironnement d’évaluation.
2 Spécifier l’évaluation : Définir la portée de l’évaluation, c’est-à-dire l’unité organisationnelle impliquée dans cette évaluation, ainsi que la sélection de projet et la pratique logicielle du modèle sélectionné.
3 Concevoir l’évaluation : élaborer un plan d’évaluation détaillé, décrire la mé- thode d’évaluation, déterminer le personnel requis, planifier sa disponibilité et sa préparation et établir une liste de questions d’entrevue.
4 Interviewer les participants au projet et examiner le projet : À ce stade, l’évaluateur doit examiner les documents du projet en fonction de la pratique du modèle de processus sélectionné et interroger le personnel identifié dans le plan d’évaluation pour examiner les attributs de qualité du logiciel à mesurer. Cette étape consiste à générer des résultats préliminaires à partir d’entretiens et d’examens.
5 Documenter et réviser les constats : Les résultats de l’enquête sont basés sur participant dans au moins deux entretiens différents, ou par les commentaires du participant et les documents examinés Les résultats de l’enquête ont été compilés dans le rapport préliminaire.
6 Conclure l’évaluation : Le rapport préliminaire est soumis aux participants à l’évaluation pour obtenir leur vérification des résultats de l’enquête, que la terminologie utilisée est suffisante et comprise par tous et que les résultats de l’enquête sont représentatifs de leur situation Leurs avis seront pris en considération lors de la préparation du rapport final À ce stade, des recom- mandations sont émises pour chaque groupe de résultats afin d’améliorer le processus logiciel.
7 Planifier des actions d’amélioration : Bien que l’ISO/IEC 14598-5 ne men- tionne aucune activité après l’évaluation, lorsque l’objectif est d’améliorer le processus logiciel, cette étape du plan d’action est nécessaire pour apporter de la valeur au demandeur Après une telle évaluation, le demandeur se re- trouve généralement avec une liste de résultats importants, sans savoir ce qui peut être fait et comment le mettre en œuvre Le plan de mise en œuvre per- met de définir les actions prioritaires, les rôles et responsabilités des parties prenantes et l’ampleur du retour sur investissement.
Dans le cadre de notre projet, cette méthode d’évaluation PEM documentée est très adaptée pour dériver nos méthodes de travail, comme décrit au chapitre 3.
The PEM method for process evaluation is akin to assessing the progress of aircraft construction by measuring weight This approach highlights the importance of tracking development through quantifiable metrics For more detailed insights, refer to the original source on ResearchGate.
Méthodologie d’évaluation du pro- cessus de logiciel
Notre approche retenue pour l’évaluation des processus de développement lo- giciel de FAPI est basée en grande partie sur la méthode PEM Et nous avons sélectionné 2 modèles CMMI et S3M.
1 Démarrage, composée des activités suivantes :
— Expliquer et présenter l’objectif du travail ;
— Spécifier les paramètres de l’évaluation ;
2 Évaluation, composée des activités suivantes :
— Faire les entrevues avec le personnel sélectionné et les gestionnaires ;
— Réviser et analyser la documentation et les données liées à l’application ;
— Réviser les constats et rédiger le rapport brouillon ;
— Envoyer le rapport brouillon aux participants pour validation.
3 Conclusion, composée des activités suivantes :
— Discuter des résultats avec le manager.
Phase 1 : Démarrage
Spécifier les paramètres de l’évaluation
L’objectif de cette activité est de définir le périmètre d’évaluation en fonction des dimensions suivantes : projet StarHub, modèles de bonnes pratiques et pratiques retenues de ces modèles.
The selected project must be either under construction or have been put into production in the previous year to accurately reflect the current practices of the FAPI team The evaluation encompasses project management, analysis, software development, and quality assurance activities.
In light of the nature of software development activities, which primarily involve development and maintenance projects, we have selected the CMMI and S3M models as best practice frameworks.
The selected practical dimension focuses on Supplier Agreement Management (SAM), which does not involve subcontracting It encompasses organizational training (OT), analysis and decision-making (DAR), and nearly all CMMI maturity level 2 and 3 processes These areas are included for evaluation and integrated project management (1PM), although the practices within these domains are not applicable in our current context and are therefore not prioritized.
Domaines de processus sélectionnés du
Gestion de la configuration Support 2
Assurance qualité processus et produit Support 2
Surveillance et contrôle de projet Gestion de projet 2
Gestion des risques Gestion de projet 3
Définition du processus organisationnel Gestion de processus 3
Focalisation sur le processus Gestion de processus 3
Table 3.1.1 – Domaines de processus du CMMI sélectionnés pour notre évalua- tion.
The architecture of the S3M model closely resembles that of the CMMi software model, facilitating easier reference and utilization of existing SEI documents when relevant for understanding specific software maintenance activities We focus exclusively on the process areas of the S3M model that align with those chosen from the CMMi framework.
Domaines de processus S3M Secteurs-clés de la maintenance Pratiques S3M Management des processus Focalisation sur les processus 1.0.1
Management des processus Définition des processus/services 2.0.1
Management des requêtes Management des requêtes de ser- vices et événements
Management des requêtes Planification de la maintenance 2.0.1
Management des requêtes Suivi et supervision des requêtes 3.0.1
Evolution du logiciel Coordination avant livraison et transition
Evolution du logiciel Services de support opérationnel 2.0.1
Evolution du logiciel Services d’évolution et de correc- tion
Evolution du logiciel Vérification et validation 4.0.1
Support à l’évolution du logiciel Management de versions et de configuration
Support à l’évolution du logiciel Assurance qualité services, pro- cessus et produits
Support à l’évolution du logiciel Analyse et mesure des ser- vices/logiciels
Table 3.1.2 – Domaines de processus et secteurs clés du S3M sélectionnés pour notre évaluation
Phase 2 : Évaluation
Faire les entrevues
This activity involves interviews with selected individuals based on the evaluation plan, facilitating the collection of information regarding project management phases, analysis, quality assurance, and development practices utilized by FAPI It also aims to gather feedback from various stakeholders on the ongoing process and their level of satisfaction To ensure a thorough evaluation, a set of questions has been prepared (see appendix).
Réviser et analyser la documentation
This activity is a crucial component of the evaluation plan, facilitating the review and analysis of various related work products It encompasses documented processes for different FAPI activities, specification documents, test plans, project management activities, and any other artifacts generated or utilized by the team.
Document de gestion de projet Excel 2
Processus de développement Document Word, Wiki 2
Plan de test Document Word, Wiki 3
Table 3.2.1 – Liste des documents révisés et analysés
Rédiger les constats
This activity involves formulating insights based on notes and observations collected during the evaluation and analysis of documents from the FAPI campaign A key aspect is ensuring that each finding is written in a way that does not identify the individual from whom it originates, to prevent any potential blame later on We also prioritize the confidentiality of observations and notes Therefore, a finding will only be considered valid if the same observation is noted in two separate interviews or if it occurs in both an interview and an analysis of an artifact or document.
Aucune observation ou note non fondée ne sera prise en compte lors de la ré- daction des conclusions, car elles seront plus anecdotiques que factuelles.
The primary deliverable of this activity is the draft report, which uniquely identifies each finding These findings are also verified by the project director to ensure their anonymity and the appropriateness of their documentation.
Envoyer le rapport brouillon aux participants pour validation 34
During this activity, the draft report from the previous session is presented to participants for validation, ensuring the protection of their statements and the confidentiality of interviews Participants are then requested to email their feedback, including any results that need revision, correction, or those they believe are missing or unnecessary For each comment, they are asked to identify findings that require a revision of the report, except for the missing findings.
Nous avons donné aux participants une semaine pour nous envoyer leurs com- mentaires.
Phase 3 : Conclusion
Finaliser le rapport d’évaluation
After presenting the survey results, we will incorporate relevant opinions into the report Chapter 4 will include findings from the investigation into the FAPI development process, while Chapter 5 will offer recommendations for the FAPI team.
Discuter des résultats avec le manager
At the conclusion of the project, a meeting with the manager is scheduled to provide recommendations and assist FAPI in developing an action plan if they wish to proceed with these suggestions.
Résumé de la méthodologie
Figure 3.4.1 – Résumé de la méthodologie concepteurs de logiciels, si deux sont d’accord sur la même chose, c’est une majorité
This chapter presents the results of the evaluation, highlighting relevant findings from each process area within the CMMI framework addressed in this project The findings are organized by process area category.
Gestion de projet
La gestion de projet dans l’équipe de FAPI
A FAPI, la gestion des projets de développement comprend les activités sui- vantes :
— Définition des tâches et responsabilités.
— Affectation des tâches de développement aux membres de l’équipe.
— Présentation des spécifications par l’analyste aux développeurs et personnel de l’AQ.
— Suivi journalier de l’état d’avancement lors d’une rencontre
— Utilisation d’Excel pour faire le suivi et le découpage du projet
Constat 1 : Processus standardisé
At FAPI, a standardized process for all activities streamlines project planning For every development project, the manager will carry out a series of activities, allowing for effective control over the project.
— Au début de chaque nouveau projet, le manager définit les tâches et les responsabilités, et attribue les tâches de développement aux membres de l’équipe en fonction de leur expertise.
— Les managers perỗoivent rộguliốrement les tõches pour rộpondre aux ten- dances du marché et aux attentes des clients.
Daily morning meetings allow the manager to monitor the project by comparing the actual workload with preliminary estimates based on last week's completed tasks This process enables the adjustment of progress and the implementation of corrective actions whenever discrepancies are identified.
Constat 2 : Gestion informelle et passive des risques
Malgré l’absence d’un plan formel de gestion des risques, FAPI répond généra- lement aux risques au bon moment et de la bonne manière en raison des facteurs suivants :
— Basé sur des années d’expérience accumulée dans la résolution de risques similaires.
Managers are acutely aware of the software's capabilities and limitations As a result, they refrain from engaging in requests that could lead to major accidents or pose excessive risks, thereby mitigating certain types of hazards.
— La flexibilité de l’affectation des tâches permet de corriger les problèmes. Par conséquent, les risques qui se présentent seront traités rapidement, bien que de manière passive.
Gestion de processus
Constat 1 : Processus organisationnel défini
FAPI clearly outlines its organizational process, detailing the software lifecycle and various activities required at each development stage, with this information stored on the team's wiki Guidance is provided for key activities such as prototyping, coding conventions, unit testing, compilation, source code review, and implementation of changes While this defined process is well understood by long-term team members, it remains unfamiliar to new employees.
Constat 2 : Pas de mécanisme d’amélioration continue
The FAPI team was unaware of the issues within their processes that needed to be addressed for improvement For instance, despite several team members being familiar with the technique, there is no retrospective conducted at the end of a cycle or project.
Processus de support
Constat 1 : Normes de programmation définies et appliquées 41
To enable developers to read each other's code effectively, FAPI requires a consistent coding standard Consequently, internal documentation outlining these standards is available for reference This documentation offers a comprehensive, precise, and detailed description of syntax and semantics, including information on file organization and naming conventions, namespace usage, class and interface declarations, annotation usage, variable initialization and naming, as well as the use of anonymous methods and Lambda expressions.
Pour garantir le respect des conventions de nommage, FAPI a mis en place une variété d’outils et de méthodes :
— Utilisation de modèles : FAPI a développé des modèles Une fois que les développeurs les utiliserons, une grande partie des règles internes standards seront automatiquement mises en œuvre et suivies.
— Utilisation des outils de vérification de style ó chaque utilisateur peut confi- gurer l’ensemble des règles qui répondent à son besoin.
Et finalement, le code des employés récents est révisé notamment pour assurer l’application des normes internes (voir le domaine dans la catégorie Ingénierie).
Constat 2 : Outils mis en place pour la gestion des modifi-
To effectively manage system modifications, FAPI has implemented a comprehensive set of tools that ensure product compliance with requirements throughout its lifecycle Additionally, for security reasons, FAPI has established controls to define and implement procedures for storing and archiving critical data, ensuring that this information remains accessible and available while managing backup and restoration processes To achieve these objectives, FAPI utilizes SVN for software version management, monitoring change requests and production events, while tracking all submitted requests and documenting the analysis scale and request allocation process.
Constat 3 : Gestion de l’intégrité des versions
Chez FAPI, les environnements de test, de développement et de production sont séparés Il existe également une procédure (manuelle) pour construire la version.
Although there is no configuration audit, SVN can automate the process of generating a clean version of the repository Each software version is stored on a separate SVN branch, and there is a clear versioning strategy that differentiates between production and development versions The version control software also maintains an audit trail of all versions deployed in production.
Constat 4 : Documents relatifs à la gestion de configuration
FAPI has developed numerous programs and lists related to configuration management, including compilation, deployment, registration, database scripting, workstation configuration, tool installation, and SVN usage, such as creating a new code branch and utilizing custom scripts These documents are available on the team's wiki or SharePoint; however, they are rarely accessed, as indicated by the low view counts, often showing only a single view per document This raises questions about whether the defined practices are being effectively implemented For instance, when a new colleague inquires about a specific procedure, information is typically passed down verbally from an experienced colleague.
Constat liés à l’ingénierie
Constat 1 : Environnements de test définis et utilisés
FAPI a mis en place l’environnement de test suivant :
Unit testing: Once coding is complete, the developer creates a unit test to ensure that the developed function meets the initial requirements and does not introduce any regressions These tests enable a quick assessment of the version's quality and ensure that previous functionalities remain unaffected by the changes.
— QA : Effectuez tous les cas de test fonctionnels après le codage.
These environments enable team members to conduct in-depth testing to identify and resolve as many bugs as possible before the release of the version Experienced team members are well-versed in these environments and utilize them on a daily basis.
New employees often lack a systematic understanding of client environments, especially when attempting to replicate them to identify errors To address this, experienced team members must dedicate time to explain and demonstrate the process of client environment replication.
Constat 2 : Architecture du logiciel définie et stable
At FAPI, software architecture rarely changes; any evolution aims to leverage the organization's predefined development framework All product additions or modifications must adhere to this framework's guidelines Developers begin implementing the source code upon receiving the final version of the detailed specification document, without needing to create a separate design document, due to the existence of a universal design Additionally, the use of templates requires each developer to implement all methods defined in the development framework in the correct execution order.
Some developers consider the web forms architecture in ASP.NET to be outdated, favoring the newer Model-View-Controller (MVC) architecture instead Both architectural styles are utilized within the ASP.NET framework.
De plus, certains développeurs ont quitté FAPI car ils souhaitaient utiliser une ar- chitecture plus moderne Cette architecture est donc un frein au recrutement de nouveaux développeurs.
Constat 3 : Exigences validées et vérifiées par plusieurs per- sonnes
Le FAPI ensures that all project members understand and review the requirements and expectations of the documentation, with each member having a specific area of intervention Whenever a business analyst drafts a requirements document for a new module or in response to legislative changes, they hold multiple meetings with the president to ensure the document aligns with their vision and guidance The analyst collaborates with experienced developers to determine the requirements and feasibility of the proposed solution, and works alongside the quality assurance manager to verify the accuracy, testability, and consistency of the specifications with the product description Additionally, the analyst conducts a peer review with another analyst to ensure thoroughness.
Constat 4 : Processus de développement itératif et incrémental 45
At FAPI, the development process is both iterative and incremental, allowing for continuous integration of functions over time This approach enables analysts to verify the accuracy of features early on and present them to the internal client, the president Additionally, it helps testers become acquainted with new applications and prepare test cases However, only after the completion of a full module will it be delivered to external clients for production.
Sommaire des constats
Following our evaluation, we found that FAPI engages in several activities recommended by CMMI across four process area categories: Project Management, Process Management, Support, and Engineering Key strengths include a defined and standardized organizational process, effective risk management, established programming standards, tools for change management, version integrity management, defined and utilized testing environments, a stable software architecture, requirements validated and verified by multiple stakeholders, as well as an iterative and incremental development process alongside prototyping.
However, FAPI should pay special attention to certain weaknesses specifically related to risk management, continuous improvement mechanisms, infrequently accessed configuration management documents, and process management This is crucial for ensuring that when there is nothing more to add, there is also nothing left to take away.
In this chapter, we present recommendations derived from the observations in Chapter 4 and the best practices in software management outlined in CMMI Each recommendation is detailed by the following characteristics:
1 Le lien avec un ou plusieurs constats ;
2 La priorité de mise en œuvre selon notre interprétation des retombées po- tentielles et positives sur le processus de développement ou sur la qualité ;
— Court terme : moins de trois mois ;
— Moyen terme : trois à douze mois ;
— Long terme : plus de douze mois.
3 Le niveau d’effort requis avec la convention suivante :
— Faible effort : facilement intégrable dans les activités quotidiennes, sans dérangement significatif pour les projets en cours ;
— Effort moyen : moins de 80 heures, soit l’équivalent de deux semaines d’effort ou moins pour une personne ;
— Effort élevé : plus de 80 heures.
Le degré d’autonomie de mise en œuvre par les employés actuels de FAPI avec la convention suivante :
— Élevé : FAPI a les compétences requises parmi les membres d’équipe ;
— Moyen : une formation d’appoint doit être suivie par un ou plusieurs membres d’équipe (lectures dirigées, formation en classe ou en ligne, coa- ching à temps partiel, etc.) ;
— Faible : FAPI n’a pas les compétences requises et doit faire appel à des experts externes.
La prioritộ suggộrộe, soit l’urgence perỗue de mettre en œuvre cette recom- mandation, avec la convention suivante :
— Élevée : FAPI devrait entreprendre cette recommandation rapidement (moins de trois mois) car elle apportera beaucoup de valeur avec peu d’effort ;
— Moyenne : Recommandation ayant beaucoup de valeur mais nécessitant un peu plus d’effort (entre trois et douze mois) ;
— Faible : Recommandation qui apporte de la valeur mais dont les risques ou les efforts de mise en œuvre sont plus élevés (dans plus de douze mois).
Ces recommandations sont regroupées et décrites dans les rubriques suivantes afin de faciliter l’élaboration d’un plan d’action :
Recommandations liées à la gestion de projet
Recommandation 1 : Évaluer les risques de manière plus rigoureuse
Constats Effort Autonomie Priorité Horizon Constat 1 Faible Elevée Faible Court terme
— Objectif : éviter les mauvaises surprises qui affectent négativement la durée des tâches
Utilizing TFS, establish and manage a register of potential risks that have not yet materialized but could impact delivery timelines, productivity, or quality For each identified risk, we provide a concise description of the issue, its level of impact, specific preventive measures to mitigate the risk, and defined actions to take when the risk occurs.
Additionally, TFS facilitates the creation and maintenance of an obstacle log for each issue that arises, detailing the actions taken to resolve them This list of obstacles serves as a valuable resource for review purposes.