Category Archives: Development Models

Project Prerequisites: 3 types of tools no project should start without

You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.

There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).

Some kind of a project management tool or a task tracker
Version Control System (VCS)
Continuous Integration (CI) framework with jobs for each phase from the build to deployment

I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development.
Continue reading →

Software Development Models: Iterative and Incremental Development

2 Replies

Waterfall Model
Iterative and Incremental Development

Iterative and Incremental Development

Iterative development was created as a response to inefficiencies and problems found in the waterfall model. Modified Waterfall, Rational Unified Process (RUP) and most, if not all, agile models are based on iterations.

General idea is to develop a system through iterations (repeated cycles) and incrementally (in small portions of time). Through them team members or stakeholders can learn from their mistakes and apply that knowledge on the next iteration.
Continue reading →

Software Development Models: Waterfall

Waterfall model

The waterfall model originated in manufacturing and construction where changes are costly and investment in design of the production line is often much less than potential loss if the actual production fails. It is based on idea that planning and design costs are much lower than those used in the actual production.

## Software development life-cycle (SDLC)

The software waterfall model often uses some variation of following phases:

Requirements specification (Requirements Analysis) resulting in Requirements Document
Software design resulting in Software Design (SD) document
Implementation resulting in the actual software
Integration
Testing (or Validation)
Deployment (or Installation)
Maintenance
Continue reading →

To work together or NOT to work together

Leave a reply

I tend to discuss things openly and often with my colleagues. Before I start Google-ing for some solution, before I start banging my head around some problem or before I start designing an application or some new feature, I tend to consult my coworkers and see whether their experiences might help. At other times, I see someone’s commit and became curious about the reasons for the way that someone implemented the solution or I might see the better way to do something. The list goes on and on… In all those cases, I prefer to get up, pair with someone and work it out. Ideally, that someone is sitting next to me. Those I communicate with do not seem to mind. Quite contrary. Unless they are very good at pretending, they act in a similar fashion and seem to do the same with me. All in all, there is a lot of communication going on, great ideas floating around and, ultimately, some kind of shared knowledge and ownership is established. I truly believe that those discussions are what makes us all better professionals.