ISS Art company logo
Go back
What you should know about software development process
Categories: General

by Olga Rekovskaya

no tags

In our previous post we've covered the topic of choosing the right outsourcing provider. Now, with that knowledge in mind, we can dive deeper into software development process itself.

As an experienced provider featured among Eastern Europe Software Development Companies, we are happy to provide you with a brief overview of software development methodologies and cover the common software development process stages together with the challenges each of them can bring to you.

Software development philosophies overview

Software development method means a framework that is used to structure, plan, and control the process of developing an information system.[1] There are various software development methods – Agile, Scrum, Extreme Programming, Test Driven Development, Waterfall, and more. The full list can be found here.

The table below should give you general idea of what it is all about.

MethodDescriptionWhen to Use ItPrimary Modeling Artifacts

| Agile Data (AD) | A partial agile method which focuses on techniques which support evolutionary (iterative and incremental) database development. | Tailor the AD philosophies and techniques into other evolutionary processes. | Agile data models | |---|---|---|---| | Agile Model Driven Development (AMDD) | A partial, practices-based method which describes techniques for effective modeling and documentation of systems. | Tailor the AM principles and practices into other agile or near-agile processes. | Apply the right artifact for the situation at hand. | | Code and Fix | A typically ineffective approach to development, usually followed by unskilled or poorly skilled developers, where they simply write code without putting much thought into it. Also called "hacking" or "immature development". | For throw-away prototypes. | Source code | | Data-Driven Approach | This is a generic category of data-driven methods popularized in the 1970s and 1980s with the emergence of structured methods. This approach is typical rigorous and serial. For a humorous look, read The Glacial Methodology | Development of a data warehouse, although a usage-centered approach is still preferable. Development of a simple "CRUD" (Create Read Update Delete) business application. | Conceptual data model Logical data model Deployment architecture Physical data model | | Dynamic System Development Method (DSDM) | This is an agile method that has received ISO 9001 certification. In many ways it is a formalization of the Rapid Application Development (RAD) methods of the 1980s. | Development of a user interface intensive system. Complex business application. | Functional prototype Design prototype | | Enterprise Unified Process (EUP) | A rigorous, multi-phased software process that includes development, operation, and retirement of software-based systems. Development efforts are iterative and incremental, better yet agile and ideally disciplined agile. It includes a multi-system view that includes enterprise architecture, reuse management, portfolio management, and people management activities. | Need to manage a portfolio of projects, including but not limited teams following the DAD. You have been successful at several DAD projects and wish to now take the full system lifecycle into account. | Enterprise business model Enterprise domain architecture model Enterprise technical architecture model Project-level artifacts | | Extreme Programming (XP) | An agile development method that focuses on the critical activities required to build software. | Small, co-located project teams (4-10 people). Requirements are uncertain. Good relationship (potentially) exists with project stakeholders. | User stories Architectural metaphor/strategy Class responsibility collaborator (CRC) cards | | ISO/IEC 12207 | A multi-phase software process that includes development, operation, and retirement of software-based systems. | Medium to large project teams (20+ people). Mandated (e.g. by government) to follow this approach. | Shall statements Logical data model Logical process model Physical data model Physical process model | | Object Oriented Software Process (OOSP) | A rigorous, CMM Level 5 (when fully instantiated), process whose focus is on the development, operations, support, and maintenance of systems using object-oriented and/or component based technologies. | Medium to large project teams (10+ people). | Use-case model System architecture model UML Sequence diagrams UML class model Physical data model | | Personal Software Process (PSP) | A prescriptive software process for individual developers. | 1 | TBD | | Scrum | An agile method whose focus is on project management and requirements management. Often combined with XP. | Any size project | Varies, depending on the development process (XP, …) which you use Scrum with. | | Test Driven Development (TDD) | An evolutionary approach to development where you must first write a test that fails before you write new functional code. Also known as test-first programming or test-first development | Any size project | Tests |


Which one to follow will depend on the type of the project you are working on – technical, organizational and team considerations matter. We won't go into detail here as long as there is already plenty of information on this subject on the Internet.

Stages of software development process

Now let's review the common stages of software development process and highlight the potential pitfalls one should be aware of.

Pre-project stage

Needless to say, it is always unpleasant to find out that you and Provider misunderstood each other after the contract was signed and the work began. To avoid such "surprises", be sure to negotiate the following important points beforehand:

1) The project concept and scope

On the pre-project stage the Provider normally presents you a finalized project concept with a brief description of functionality and optimal collaboration model choice. In addition, the preliminary project estimate is made. We recommend you to get familiar with all the assumptions based on which the estimate is made, so that you have a better understanding of how the project cost is determined. Feel free to ask your Provider if anything seems unclear – communication is the key to mutual understanding.

2) Phases/milestones and their acceptance

Typically, large projects are split into phases. Upon each phase completion the Provider presents the results of work to you. Be sure to study the project plan carefully and negotiate how work acceptance will happen. For example, in our company we sign a work acceptance certificate with a Customer upon a phase/milestone completion.

3) Budget and timeline

Project development budget and timeline will depend not only on the project scope, but also on the team composition. Ask your Provider which specialists will work on your project, and what will be their workload. Please note that more specialists do not always mean faster completion – the more team members involved, the more communication expenses arise.

4) Signing the contract

After negotiating the project scope, delivery timeframes and budget make sure everything you've discussed is covered in the services agreement you are going to sign. Don't forget about the source code ownership – who will possess ownership rights? This should be stated in a contract as well. In our company, for example, the exclusive ownership rights are handed over to the customer upon the project completion.

Ask your lawyer for help to review the contract if needed.

Project Development

1) Project Analytics and Specification creation

As mentioned in one of our previous articles, project analytics and specification creation enable reducing development costs and describing the requirements as accurately as possible. This is aimed to ensure that the developers clearly understand the goal and final results.

Technical specification creation may consist of the following artifacts:

  • user stories – options of user interaction with the system;
  • interface templates of the projected system;
  • functional requirements to the system;
  • non-functional requirements to the system (that is performance, reliability, usability, security requirements, etc.);
  • various schemes and diagrams to illustrate user-system interaction and different structural units interactions (pages, forms, interaction types, etc.).

The list of artifacts for each project is defined individually depending on the type and project scale. The smaller the project, the fewer artifacts there are.

2) Architecture design

At this step the high-level system design is normally created. In addition, a prototype of the project or of some part of it can be created. Your task here is to spend as much time as possible to test this prototype. The earlier non-conformances are discovered the cheaper the corrections will be.

Also, it is important to think about the potential of you future system. If it has a potential to become highload with time, it should be designed in a way that would support the increased volume of requests and computations.

Some Providers make a separate estimate for this activity, others include it into the development estimate. If you don't see this activity in the project estimate, ask Provider whether it is included in it. The estimate should include at least minimum time for architecture design.

3) Graphic design

If you don't have in-house designer, you will have to outsource this part of work to a third-party specialist/company. When doing so, make sure the designer is not going to use other designers' works. If he is going to purchase images, ask him to show you the payment documents. If the designer uses free images, make sure their usage does not violate ownership rights.

You can read more on this subject in one of our article about IP issues.

4) Development

The development stage actually assumes the program code creation process. You may want to have access to the source code during the whole development process. Normally with Time and Materials model you are given the access to the source code. With Fixed Price model you will have to initially agree with Provider after what stage to hand the source code over to him. Anyway, this is to be discussed with your Provider.

Make sure that Provider documents the code. This is an important aspect that greatly influences readability and plainness for other developers.

5) QA process (testing)

Software testing is a program product trial run that aims at two different things:

  • Demonstrate developers and customers that the software meets the requirements;
  • Find out conditions when the software behavior is wrong, unwanted or does not meet the requirements.

At this stage it is important to make sure that the Provider has all the necessary equipment to provide the testing (hardware, devices, etc.).

6) Deployment

At deployment stage the source code is supposed to be transferred by Provider to your server (or your hosting provider's server). However, you can refuse from this service, if you plan to place the code on your server (or your hosting provider's server) on your own.

Were any project documents (i.e. user manual) created on your request? If so, they should be handed over to you as well.

Maintenance and Support

Most of the times project completion does not mean the end of the work – when a product is put to the operation, the project can transferred to the maintenance stage. The main aim of the maintenance stage is monitoring of the resulting product performance.

The software maintenance works may include (but are not limited to):

  • software faults and defects prevention;
  • timely software update to provide its correct functioning;
  • necessary software modifications to maintain and increase its demand in the market.

We recommend ordering project maintenance with Provider, since the team already knows the product and can easily deal with coming requests. Besides, no one wants to deal with somebody else's code.


We've covered the most common aspects that should be taken into account so far.

Please note that even the most well-known projects do not always start with the most feature-rich version. Therefore, we recommend starting a project with prototype development (proof of concept). The sooner you launch the project onto the market, the better.

Have something to add? Feel free to share your thoughts in comments.

References: [1] [2] [3]