探索性程序开发风格是一种非正式的开发风格，其中程序员使用自己的直觉来开发程序，而不是利用归类于软件工程学科的系统知识体系。这种开发风格使程序员可以完全自由地选择他们喜欢开发软件的活动。这种样式不提供任何开始开发任何软件的规则。下面的框图将清除一些与此模型有关的事实：
图–探索性的软件开发风格
在上图中，第一个方框是客户的初步简介，即客户的问题简介。简报后，控制权将转到初始编码，即，一旦开发人员或程序员知道问题，他便开始进行编码以开发工作程序，而无需考虑任何类型的需求分析。此后，将对程序进行测试，即发现错误，并由程序员修复它们。这个循环一直持续到没有获得令人满意的代码为止。找到令人满意的代码后，开发就完成了。
用法 ：
这种软件开发风格仅用于开发小程序。如今，这种风格仅在实验室中被学生用来完成作业。如今，这种样式在行业中并未真正使用。
此模型有什么问题?
在探索性开发方案中，开发专业软件所需的精力和时间随着程序大小的增加而增加。下图显示了开发工作量和出现问题的时间的增加：
图–随着问题大小的增加，开发时间和工作量增加。
在上图中，粗线图表示使用探索性风格开发程序的情况。随着程序大小的增加，所需的工作和时间几乎成倍增加。对于大问题，使用探索性开发风格来开发程序在实践上有意义将花费很长时间并且花费太多。据说，在待开发程序的大小增加到超过一定值之后，探索性开发方法就会崩溃。
细实线用于表示使用软件工程原理进行开发时的情况。在这种情况下，可以解决费时费力的问题，在程序大小上几乎是线性的，虚线表示通过自动机器进行显影时的情况。在这种情况下，工作量和时间随尺寸的增加甚至会更接近于尺寸的线性增加。
探索风格导致由于人类认知限制而使问题的感知困难成倍增长。您可能仍然想知道，当使用软件工程原理时，为什么曲线不能完全变成线性?答案是，很难应用分解和抽象原理来完全克服问题的复杂性。
该模型的缺点：
- 使用这种模型，开发时间和工作量呈指数级增长，随着问题规模的增加，使用这种开发风格，大型软件几乎变得不可能。
- 这种开发风格导致代码无法维护，因为没有计划就进行编程总是会导致代码的结构化和质量下降。
- 另外，在有合适的开发团队的情况下，很难使用这种样式，因为每个开发人员都使用自己的直觉来开发软件。