polski (Polska) English (United States)

Questions? Comments?
Call us!
Intl. acc. code
+48 42 2153435
Or give us an email:
office at proinet.pl

Software Process

Software Process is sometimes regarded to be a critical issue for a successful IT project. Depending on the project scale Proinet uses a few SP types. We usually work in small teams on projects requiring up to 200 MD. These kind of projects taking for 3-8 persons are optimal for agile methodologies. We can also support OpenUP/Basic if required.

Each software process usually contains certain disciplines, like:

  • business modelling
  • requirements gathering
  • analisis and project
  • implementation,
  • testing,
  • deployment.

Our activities focus on fast delivery of the working system. Overblown formalism during business modeling, requirements gathering or analisis won't help reducing development time. At the beginning phase we have two parties - customer and software architect that have two different visions on the system. Talking about the system, drawing it's architecture, creating use cases and showing scenarios may be a good start to find a vision that is common for both parties. However there is nothing like working prototype. It's better to have one as a common starting point for further discussion. Our preferred software process aims to avoid extending the system with unnecessary features at inception phase. Instead we follow good design practices that state that a good project must be minimal. Once we gather core requirements we try to choose future system's architecture and to prepare prototypes.

We also like to have fast transition of the working system to customer. It gives us immediate feedback, helps to prove key concepts or find misconception. This is typical for agile methodologies where customer is involved in software process all the time.  Many software developers avoid releasing the software until every potential bug is tested-out. However this shoots back when customer finds a serious misconception lately.  We remember that every problem is easier to solve at early stages. The longer you delay the transition the more resources you have to spend on fixing bugs. As you can see - our work style is really what OpenUP/Basic says.

We find agile methodologies help in our software projects. But we just don't buy every word from it. For example XP (eXtreme Programming) maybe really very successful methodology - it's test-driven, it has small iterations, it's continuos integration rules automates tedious testing and building tasks. It works for us. However if we find that some working system could be really refactored a bit just because code smells we ask ourselves - is the cost of change adequate to the result? What potential risk we create if we refactor? Satis est satius ancient said, which means that better is good's worst enemy.