Methodology and Software Tools in Software
Engineering
An Advanced Academic Guide to Systems Analysis, Project Estimation, and CASE
Tools
Department of Computer Science & Software Engineering
June 19, 2026
Abstract
This academic lesson provides an in-depth exploration of software engineering method-
ologies, project cost evaluation, and the computer-aided tools used to design and de-
velop robust software systems. We present a taxonomy of development lifecycles,
followed by an exhaustive structural analysis of the French structured methodology
MERISE. Furthermore, we detail the mathematical models behind software cost es-
timation, specifically focusing on the Constructive Cost Model (COCOMO). Finally, we
categorize the software tools that automate, support, and secure the modern software
development lifecycle (SDLC).
Contents
1 General Presentation of Software Methodologies 3
1.1 Evolution of Software Lifecycles . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Key Methodology Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 The Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 The V-Model (Validation and Verification) . . . . . . . . . . . . . . . . . . 3
1.2.3 The Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Agile Methodologies (e.g., Scrum, Kanban) . . . . . . . . . . . . . . . . . 4
1.3 Comparative Summary of Methodologies . . . . . . . . . . . . . . . . . . . . . 4
2 Detailed Analysis of the MERISE Methodology 5
2.1 The Three Cycles of MERISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 The Three Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 1. The Conceptual Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 2. The Organizational / Logical Level . . . . . . . . . . . . . . . . . . . . 6
2.2.3 3. The Physical Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Evaluation of Cost in Detailed Study and Development 7
3.1 Standard Estimation Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 The COCOMO Model (Constructive Cost Model) . . . . . . . . . . . . . . . . . . 7
3.2.1 Project Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Mathematical Formulations . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Step-by-Step Practical Calculation Example . . . . . . . . . . . . . . . . . . . . . 8
1
4 Usage of Software Tools in Conceiving and Developing Software 10
4.1 Taxonomy of CASE Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 1. Upper-CASE Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 2. Lower-CASE Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3 3. Integrated-CASE (I-CASE) Tools . . . . . . . . . . . . . . . . . . . . . . 10
4.2 The Modern Developer Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2
1 General Presentation of Software Methodologies
A software engineering methodology is a structured framework of processes, practices,
deliverables, and tools used to plan, design, build, test, and deploy an information system.
Adopting a systematic methodology is crucial to mitigating project risk, ensuring quality,
managing budgets, and facilitating long-term system maintenance.
1.1 Evolution of Software Lifecycles
Historically, methodologies have evolved from rigid, document-driven linear paths to highly
iterative, user-centric approaches. These can be grouped into three major paradigms:
a) Predictive (Traditional) Lifecycles: characterized by sequential phases where each
phase must be fully completed before the next begins.
b) Structured Lifecycle Methodologies: highly systemic frameworks focusing on sep-
arating data from functional processing (e.g., MERISE, SSADM, SADT).
c) Adaptive (Agile) Lifecycles: modern iterative frameworks focused on adaptability,
continuous feedback, working software, and customer collaboration.
1.2 Key Methodology Models
1.2.1 The Waterfall Model
Introduced conceptually by Winston Royce, the Waterfall model is a linear sequential model.
It divides the software development lifecycle into distinct, non-overlapping phases: Re-
quirements Analysis, System Design, Implementation, Integration and Testing, Deploy-
ment, and Maintenance.
• Advantage: Highly structured, easy to manage due to rigid phase-gate reviews, and
highly documented.
• Disadvantage: Extremely inflexible. High risk of project failure if initial requirements
are misunderstood, as software is only delivered at the end of the cycle.
1.2.2 The V-Model (Validation and Verification)
An extension of the Waterfall model, the V-Model organizes development steps in a V-
shape. The left side of the ”V” represents the decomposition of requirements and design,
while the right side represents the corresponding integration and validation phases. Every
design level has a matching testing phase:
• Business Requirements match with User Acceptance Testing (UAT).
• System Architecture matches with System Testing.
• Detailed Design matches with Integration Testing.
• Coding matches with Unit Testing.
3
1.2.3 The Spiral Model
Proposed by Barry Boehm, the Spiral Model is a risk-driven, evolutionary software process
model. It combines the iterative nature of prototyping with the controlled, systematic
aspects of the Waterfall model. The development progresses through four quadrants in
concentric loops:
1. Determine objectives, alternatives, and constraints.
2. Evaluate alternatives, identify, and resolve risks (via prototyping).
3. Develop and verify the next-level product.
4. Plan the next phase.
1.2.4 Agile Methodologies (e.g., Scrum, Kanban)
Agile practices prioritize working software over comprehensive documentation. Scrum di-
vides development into fixed-length iterations called Sprints (typically 1 to 4 weeks), man-
aged by a Scrum Master and Product Owner, involving daily stand-ups, sprint planning,
and retrospectives. Kanban focuses on continuous delivery, visual workflow representa-
tion (Kanban boards), and strictly limiting Work in Progress (WIP).
1.3 Comparative Summary of Methodologies
Table 1: Comparative Matrix of Core Software Methodologies
Metric Waterfall V-Model Spiral Agile (Scrum)
Flexibility Extremely Low Low Medium-High Extremely High
Risk Management Poor Poor Excellent (Native) Very Good
User Involvement Low (Start/End) Low Medium High (Continuous)
Primary Focus Process Control Quality Gateways Risk Reduction Customer Value
Deliverables At the end At the end Iterative prototypes Every Sprint
4
2 Detailed Analysis of the MERISE Methodology
MERISE (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise)
is a widely used European structured methodology, developed in France during the late
1970s and 1980s. It is optimized for designing large-scale enterprise information systems,
specifically database-driven applications.
The core philosophy of MERISE lies in the strict separation of Data (Static View) and
Treatment/Processes (Dynamic View).
2.1 The Three Cycles of MERISE
An information system design under MERISE is analyzed through three orthogonal dimen-
sions, known as the Three Cycles:
1. The Abstraction Cycle: Moving from conceptual real-world ideas to technical and
physical implementations.
2. The Decision Cycle: Strategic decision checkpoints where stakeholders assess fea-
sibility, choose options, and authorize progression to the next phase.
3. The Life Cycle: The evolution of the software from initial strategic planning, through
design, construction, maintenance, and eventual obsolescence.
2.2 The Three Levels of Abstraction
The Abstraction Cycle is divided into three distinct conceptual levels, each separating Data
and Treatment (Processes), resulting in six core system representations.
Table 2: The MERISE Abstraction Matrix
Abstraction Level Data View (Static) Treatment View (Dynamic)
Conceptual Level MCD (Modèle Conceptuel des MCT (Modèle Conceptuel des
Données) Traitements)
Organizational / MLD (Modèle Logique des MOT (Modèle Organisationnel
Logical Level Données) des Traitements)
Physical Level MPD (Modèle Physique des MPT (Modèle Physique des
Données) Traitements)
2.2.1 1. The Conceptual Level
The goal of this level is to describe the static and dynamic rules of the enterprise without
any reference to organizational changes, geographical constraints, or technical infrastruc-
ture.
• MCD (Conceptual Data Model): Represents the static structure of the information
system. It uses the Entity-Relationship (ER) model consisting of:
– Entities (or Classes): Objects of interest (e.g., Customer, Product).
– Attributes: Properties of entities (e.g., CustomerID, ProductName). Each entity
must have a unique identifier.
5
– Associations (or Relations): Connections between entities (e.g., Places, Con-
tains).
– Cardinalities: Expresses the minimum and maximum occurrences of an asso-
ciation for a single entity instance (e.g., 0, N , 1, 1, 1, N ).
• MCT (Conceptual Treatment Model): Represents the dynamic processes of the sys-
tem triggered by events. Its core vocabulary consists of:
– Events: External or internal occurrences that trigger processing.
– Synchronizations: Boolean conditions (AND, OR) defining how incoming events
combine to trigger an operation.
– Operations: A set of uninterrupted elementary processing steps triggered by
synchronized events.
– Results: Output events produced upon execution of an operation, often gov-
erned by emission rules (e.g., ”OK”, ”KO”).
2.2.2 2. The Organizational / Logical Level
This level integrates organizational choices, answering the questions: Who does what,
where, and when?
• MLD (Logical Data Model): Translates the MCD into a structure optimized for a spe-
cific class of database management systems, most commonly relational databases.
Entities become tables, identifiers become primary keys, and relationships become
foreign keys.
• MOT (Organizational Treatment Model): Adapts the MCT by defining which opera-
tions are automated or manual, identifying actors (users or departments), assigning
work stations, and establishing temporal constraints (schedules, batch execution vs.
real-time).
2.2.3 3. The Physical Level
The final level addresses the physical, hardware-dependent technical implementation.
• MPD (Physical Data Model): The actual database schema code (SQL DDL commands
like CREATE TABLE) taking into account physical indexing, partition keys, and specific
DBMS data types (e.g., PostgreSQL, Oracle SQL, MySQL).
• MPT (Physical Treatment Model): The concrete software architecture specification
(classes, functions, APIs, stored procedures, modules, and microservices) that will
realize the logical workflows.
6
3 Evaluation of Cost in Detailed Study and Development
Accurate software cost estimation is one of the most critical aspects of project manage-
ment. Underestimating leads to missed deadlines and poor quality, while overestimating
leads to lost business and wasted resources.
3.1 Standard Estimation Approaches
There are three main classes of estimation techniques:
1. Expert Judgment: Subjective estimation based on the past experiences of senior
engineers (e.g., Delphi Method).
2. Estimation by Analogy: Comparing the current project with similar, completed projects.
3. Parametric Models: Mathematically formulated models where sizing metrics (Lines
of Code, Function Points) are mapped to effort and duration based on historical em-
pirical data.
3.2 The COCOMO Model (Constructive Cost Model)
Originally developed by Barry Boehm in 1981, COCOMO remains the benchmark paramet-
ric model. COCOMO is structured into three tiers: Basic, Intermediate, and Detailed. We
will analyze the Basic COCOMO model.
3.2.1 Project Classification
COCOMO classifies software projects into three distinct development modes based on
complexity and team familiarity:
• Organic Mode: Relatively small, simple software projects. Stable environment, small
team, low risk, high familiarity.
• Semidetached Mode: Medium-sized, intermediate complexity projects. Mix of ex-
perienced and inexperienced staff, moderately rigid requirements.
• Embedded Mode: Extremely complex software developed under tight hardware,
software, and operational constraints (e.g., avionics software, real-time banking sys-
tems).
3.2.2 Mathematical Formulations
The basic model estimates two primary variables:
1. Effort (E): Measured in Person-Months (PM). This represents the labor required.
2. Development Time (Tdev ): Measured in calendar months.
3. Average Staffing (S): Measured in active persons needed.
The formulas are:
E = a · (KLOC)b (1)
Tdev = c · E d (2)
E
S= (3)
Tdev
Where:
7
• KLOC represents the estimated thousands of delivered source Lines of Code.
• a, b, c, d are empirical coefficients assigned based on the project’s development class.
Table 3: Basic COCOMO Empirical Coefficients
Development Mode a b c d
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
3.3 Step-by-Step Practical Calculation Example
Problem Statement: A software team is contracted to build an embedded aircraft control
interface. The engineers analyze the requirements and estimate that the code size will
be approximately 50, 000 lines of code (KLOC = 50). Calculate the estimated effort, the
scheduled development time, and the optimal number of developers required.
Step 1: Identify the Mode and Coefficients
Since this is an avionics/control application, it falls under the Embedded Mode. From
Table 3, the coefficients are:
a = 3.6, b = 1.20, c = 2.5, d = 0.32
Step 2: Calculate Effort (E)
Using Equation (1):
E = 3.6 × (50)1.20
Let us compute (50)1.20 :
(50)1.20 ≈ 109.856
Therefore,
E = 3.6 × 109.856 ≈ 395.48 Person-Months
Step 3: Calculate Development Time (Tdev )
Using Equation (2):
Tdev = 2.5 × (395.48)0.32
Let us compute (395.48)0.32 :
(395.48)0.32 ≈ 6.756
Therefore,
Tdev = 2.5 × 6.756 ≈ 16.89 calendar months
Step 4: Calculate Staffing Required (S)
Using Equation (3):
395.48 PM
S= ≈ 23.41 ≈ 23 full-time developers
16.89 Months
8
Summary of Results
The project will require approximately 395.5 Person-Months of effort, taking 16.9 calen-
dar months to develop with a team of 23 to 24 developers.
9
4 Usage of Software Tools in Conceiving and Developing Soft-
ware
The design, implementation, and maintenance of modern software are automated us-
ing Computer-Aided Software Engineering (CASE) tools, Integrated Development Environ-
ments (IDEs), and automated pipeline infrastructures.
4.1 Taxonomy of CASE Tools
CASE (Computer-Aided Software Engineering) tools are software applications that support
engineering activities throughout the SDLC. They are historically and functionally catego-
rized into three zones:
4.1.1 1. Upper-CASE Tools
These tools assist with the initial stages of development: requirements gathering, domain
analysis, business process modeling, and system design.
• Activities: Enterprise planning, structural database modeling, creating UML dia-
grams, or MERISE modeling (MCD/MCT).
• Examples: Enterprise Architect, PowerDesigner, Visual Paradigm, [Link], Lucid-
chart.
4.1.2 2. Lower-CASE Tools
These tools assist in the execution phases of the lifecycle, translating system designs into
operational code.
• Activities: Code generation from diagrams, compiling, linking, debugging, database
generation, and Unit Testing.
• Examples: Compiler suites (GCC, LLVM), static code analysis suites (SonarQube),
code generator wizards.
4.1.3 3. Integrated-CASE (I-CASE) Tools
I-CASE tools span the entire lifecycle, connecting requirements analysis down to mainte-
nance and source version tracking.
Integrated DevOps Toolchain Pipeline
Planning → Conception → Coding → Testing → CI/CD → Monitoring
Figure 1: Abstract visual flow of modern integrated toolchain ecosystems.
10
4.2 The Modern Developer Ecosystem
Today, discrete CASE tools have merged into modular, unified ecosystems. The major ele-
ments of a modern developer’s tool suite include:
1. Distributed Version Control Systems (DVCS): Tools like Git that track revisions, sup-
port branching workflows, and manage concurrent team development. Hosted en-
vironments like GitHub and GitLab provide code review and pull-request environ-
ments.
2. Integrated Development Environments (IDEs): Advanced source code editors (e.g.,
VS Code, IntelliJ IDEA, Eclipse) equipped with syntax highlighting, automatic refactor-
ing, built-in debuggers, and AI-assisted code generation.
3. Continuous Integration & Continuous Deployment (CI/CD): Infrastructure (e.g.,
Jenkins, GitHub Actions, GitLab CI/CD) that automates running test suites, verifying
security compliance, and packaging artifacts upon every code commit.
4. Containerization & Virtualization: Platforms like Docker and Kubernetes which
package applications into standard isolated units, ensuring the software runs iden-
tically across local development, testing, and production environments.
11