Software Process and Human-Computer Interaction
Every piece of software is shaped by two forces: the process used to build it, and the human it is built for. Understanding software process models and HCI is foundational to building products that actually work.
Every piece of software you interact with was shaped by two forces: the process used to build it, and the human it was built for. Get either wrong and the result is software that is late, broken, or simply never used. Getting both right is what software engineering is about.
This article covers two foundational topics in computing: Human-Computer Interaction (HCI) and Software Process. They are deeply connected. HCI defines who we are building for. Software process defines how we build it.
What is Human-Computer Interaction?
Human-Computer Interaction (HCI) is the field of computer science concerned with the study, design, and implementation of interactive systems built around human needs and capabilities. It sits at the intersection of three ideas:
- •Human - the people who use technology
- •Computer - the machines, systems, and software they use
- •Interaction - the communication, exchange, and conversation between the two
HCI recognizes a simple truth: technology exists to serve people. For that to happen, systems must be designed with the user at the center. Every interface decision, every workflow, every error message is a design choice that either helps or hinders the person on the other side.
The advancement of HCI research has been one of the driving forces behind the growth of the web and modern software. When software is designed with genuine human needs in mind, it gets adopted. When it ignores those needs, it fails regardless of how technically sophisticated it may be.
This is why every software engineer, computer scientist, and product builder must understand and apply human-centered design. Building something that works technically is only half the job.
What is a Software Process?
A process is a series of steps that produces a result. A software process is a set of related activities that leads to the production of a software product.
More formally, software development process is the practice of dividing software development work into smaller, parallel or sequential steps in order to improve design quality and product management. It is also called the Software Development Life Cycle (SDLC).
A well-defined software process answers four questions for every stage of development:
- •What tasks need to be performed?
- •What are the inputs and outputs of each task?
- •What conditions must be true before and after each task?
- •In what order do tasks run, and how do they connect?
Without a defined process, projects drift: requirements grow unchecked, timelines slip, and the final product rarely matches what was originally intended.
Software Process Models
A software process model is an abstraction that describes a particular approach to software development. It specifies the stages of development, the order in which they occur, and the relationships between them.
The goal of any process model is to provide a structure for controlling and coordinating development so the team reaches its objectives as effectively as possible.
Factors to Consider When Choosing a Model
No single process model fits every project. The right choice depends on the nature of the work:
| Factor | Questions to Ask |
|---|---|
| Requirements | Are they well-understood upfront, or will they evolve? |
| Project Size | How large is the team? How much coordination is needed? |
| Complexity | Are requirements unclear or likely to change frequently? |
| Cost of Delay | How expensive is it to miss a deadline? |
| Customer Involvement | Does the client need to participate throughout development? |
| Technology Familiarity | How experienced is the team with the tools and domain? |
| Resources | What are the budget, staffing, and time constraints? |
Types of Software Process Models
Waterfall Model
The waterfall model is the oldest and most straightforward approach. It is linear and sequential: each phase must be completed before the next begins, with no overlap and no going back. The model gets its name from the way development flows downward from one phase to the next.
The phases, in order:
- •Requirements Gathering - all requirements are captured in a product requirements document
- •Analysis - requirements are analyzed to define schemas, models, and business rules
- •System Design - the software architecture is designed based on the analysis
- •Implementation - software is developed in small units with functional testing
- •Integration and Testing - units are integrated and the full system is tested for faults
- •Deployment - the product is released to the production environment after all testing is complete
- •Maintenance - bugs are fixed and new versions are released as needed
The waterfall model works well when requirements are stable, well-understood, and unlikely to change. It performs poorly when requirements shift mid-project, and mistakes discovered late are expensive to fix. It remains common in government contracting and embedded systems where requirements are locked in advance.
Spiral Model
First described by Barry Boehm in his 1986 paper "A Spiral Model of Software Development and Enhancement," the spiral model adds risk management to iterative development. A project passes through four phases repeatedly, with each loop called a spiral:
- •Planning - gather business requirements; in later spirals, refine system and unit requirements through ongoing customer communication; the product is deployed at the end of each spiral
- •Design - develop architecture in early spirals; logical and physical design in later ones
- •Construct - build the product; early spirals produce a Proof of Concept (POC) for user feedback; later spirals produce versioned working builds
- •Evaluation and Risk Analysis - identify technical, schedule, and cost risks; gather user feedback; plan the next spiral
The spiral model suits large, high-risk projects where requirements are not fully known upfront and where failure would be costly.
V Model
The V Model (Verification and Validation model) extends the waterfall model by pairing each development phase with a corresponding testing phase. The two sides of the V mirror each other:
- •Requirements analysis pairs with acceptance testing
- •System design pairs with system testing
- •Architecture design pairs with integration testing
- •Module design pairs with unit testing
- •Coding sits at the bottom of the V
Testing for each phase is planned in parallel with that phase, not after it. The V model is highly disciplined and makes project management straightforward. It is a strong choice for systems where failure is unacceptable, such as medical devices or aviation software. It is poorly suited to projects with unclear or changing requirements.
Incremental Model
The incremental model divides the system's total functionality into increments that are built and delivered in sequence. The most important features are implemented first, and each subsequent increment builds on what came before.
Each increment passes through its own cycle of requirements, design, coding, and testing. Key advantages:
- •Stakeholders see working software from the first increment
- •Problems are discovered early, when they are cheaper to fix
- •Developers focus on the highest-priority work at each stage
The incremental model requires a clear and complete definition of the total system before development begins. It works well for projects with loosely coupled components and well-understood requirements.
Iterative Model
The iterative model develops a system by building small portions of all features at once, rather than complete features one at a time. Each iteration produces a more complete version of the system, which is reviewed to identify further requirements.
Development begins with a minimal implementation of the full scope. Each pass refines and expands that implementation based on feedback, continuing until the system is complete.
The iterative model handles changing requirements well, reveals design flaws early, and manages risk effectively on large, complex projects. It is a natural fit for software that can be decomposed into repeatable development cycles.
RAD Model
Rapid Application Development (RAD) is an iterative approach that emphasizes speed and user involvement over extensive upfront planning. Development phases run in parallel to compress timelines:
- •Business modeling
- •Data modeling
- •Process modeling
- •Application generation
- •Testing and turnover
RAD relies on workshops and focus groups to capture requirements quickly, reuses existing components wherever possible, and favors informal communication over heavy documentation. It reduces development time and accommodates changing requirements, but requires experienced developers and can be difficult to manage at scale.
RAD is best suited to projects with known requirements and tight delivery schedules.
Agile Model
The Agile model combines iterative and incremental approaches with an emphasis on adaptability, collaboration, and customer satisfaction. Rather than delivering a finished product at the end of a long cycle, Agile delivers working software in short iterations called sprints, typically lasting one to three weeks.
Each sprint involves cross-functional teams working simultaneously across:
- •Planning
- •Requirements analysis
- •Design
- •Coding
- •Unit testing
- •Acceptance testing
At the end of every sprint, a working product increment is demonstrated to the customer and stakeholders. Feedback shapes the next sprint.
Agile recognizes that requirements will change and that no project unfolds exactly as planned. Instead of fighting change, Agile processes are structured to accommodate it. The focus is on delivering the highest-value features first and continuously improving based on real feedback.
Agile methods include Scrum, Kanban, and Extreme Programming (XP). They have become the dominant approach in commercial software development because they align well with how software projects actually unfold in practice.
Prototype Model
The prototype model builds a working model of the system before full development begins. The prototype is shared with users to gather feedback, and that feedback shapes the final product requirements.
This approach is valuable when requirements are unclear or when the user interface is critical and difficult to specify in writing. The prototype is typically discarded or heavily revised once requirements are confirmed and the real system is built.
HCI and Process: Two Sides of the Same Goal
Software process models address how to build software efficiently and predictably. HCI addresses who the software is being built for and what they actually need.
These two concerns are not separate. Agile and iterative models are structured around continuous user involvement and feedback, which is a direct expression of HCI principles applied to the development process. Every sprint review is, in essence, a usability session. Every piece of customer feedback is a signal that the product is or is not meeting human needs.
The most successful software is built by teams who take both seriously: a disciplined process that keeps the work on track, and a genuine commitment to understanding and serving the humans who will use what they build.
That combination is not optional. It is the baseline for building anything that matters.
