MyPage is a personalized page based on your interests.The page is customized to help you to find content that matters you the most.


I'm not curious

Which software development models you need to know?

Published on 31 March 15
545
0
2

For regular customers who come up with a project need software development model (or methodology) doesn't mean anything. They don't need to know about it, neither do they care. They need final result - software which they will use. The way you have developed it and the models you have used for it are solely your decision.

But from the point of view of a software development company, using this or that software development model can lead to different results and may require different amount of efforts.

Which software development models you need to know? - Image 1

Waterfall model

This is one of the oldest development methodologies. This model was first described back in 1970 and presumes consecutive fulfillment of the following stages:

  1. Requirements development: a project manager gathers all the possible information about the project from a customer and then turns it into functional requirements for developers.
  2. Analysis and design: development of a domain model, projection of a database, user interface, etc.
  3. Implementation: creation of a project according to the specification, provided at the previous stage.
  4. Testing: product validation and debugging (if necessary).
  5. Deployment: user education, system installation, product implementation.

If there's an error in the process of software development, it usually causes some problems for developers. But far worse when such an error appears in a fully developed application. Waterfall model strives for detecting possible errors at the stage of analysis.

But waterfall model performs worse for the projects with unclear requirements or with requirements that may be changed in the process of development. There're also some other disadvantages. For example, it's more difficult to manage some types of risks (for example, risks connected with the use of new technologies). Such risks can appear on the implementation stage or testing stage, when thereÑÐЩre fewer possibilities for fixing issues.

That's why bright minds have come up with another solution based on waterfall model. This solution is iterative model.

Iterative model

Iterative development is a waterfall methodology descendant. Development process consists of a series of repetitive iterations (their number depends on the project). Each iteration is a project in itself with all the due stage of analysis, development, testing, etc. After another iteration a product gets new functionality or gets improved existing one. Full set of requirements within a project is implemented after finishing the final iteration.

Such development methodology allows minimizing risks of implementing new technologies, changing project requirements, errors in code, etc.

RUP

RUP (or Rational Unified Process) was developed by IBM corporation. RUP methodology describes a general process, on the basis of which a dedicated development team can create a process which serves certain project.

Within RUP we can define the following characteristics:

Requirements development. The basis for requirements development in this process is the so-called usage precedents (which mean scenarios of user interaction with a program). Different models of usage precedents are created and they should describe possible ways of using the program or app in all variants.

Iterativity. As it has been mentioned above, RUP is based on the iterative model. Creators of the RUP recommend at the beginning of every iteration detecting the precedents which should be implemented at the moment. But make sure that each iteration is not very long.

Project cycle. RUP means the use of four stages: inception (the information about the project is gathered, time limits are set, precedents are developed, etc.), designing (optional stage, which contains more detailed description of the precedents, main risks mitigation, etc.), development (development of a final project) and implementation.

Conclusion

Surely, these are not all software development methodologies. There're other ones which sometimes even more suitable on this or that project.








For regular customers who come up with a project need software development model (or methodology) doesn't mean anything. They don't need to know about it, neither do they care. They need final result - software which they will use. The way you have developed it and the models you have used for it are solely your decision.

But from the point of view of a software development company, using this or that software development model can lead to different results and may require different amount of efforts.

Which software development models you need to know? - Image 1

Waterfall model

This is one of the oldest development methodologies. This model was first described back in 1970 and presumes consecutive fulfillment of the following stages:

  1. Requirements development: a project manager gathers all the possible information about the project from a customer and then turns it into functional requirements for developers.
  2. Analysis and design: development of a domain model, projection of a database, user interface, etc.
  3. Implementation: creation of a project according to the specification, provided at the previous stage.
  4. Testing: product validation and debugging (if necessary).
  5. Deployment: user education, system installation, product implementation.


If there's an error in the process of software development, it usually causes some problems for developers. But far worse when such an error appears in a fully developed application. Waterfall model strives for detecting possible errors at the stage of analysis.

But waterfall model performs worse for the projects with unclear requirements or with requirements that may be changed in the process of development. There're also some other disadvantages. For example, it's more difficult to manage some types of risks (for example, risks connected with the use of new technologies). Such risks can appear on the implementation stage or testing stage, when thereÑÐЩre fewer possibilities for fixing issues.

That's why bright minds have come up with another solution based on waterfall model. This solution is iterative model.

Iterative model

Iterative development is a waterfall methodology descendant. Development process consists of a series of repetitive iterations (their number depends on the project). Each iteration is a project in itself with all the due stage of analysis, development, testing, etc. After another iteration a product gets new functionality or gets improved existing one. Full set of requirements within a project is implemented after finishing the final iteration.

Such development methodology allows minimizing risks of implementing new technologies, changing project requirements, errors in code, etc.

RUP

RUP (or Rational Unified Process) was developed by IBM corporation. RUP methodology describes a general process, on the basis of which a dedicated development team can create a process which serves certain project.

Within RUP we can define the following characteristics:

Requirements development. The basis for requirements development in this process is the so-called usage precedents (which mean scenarios of user interaction with a program). Different models of usage precedents are created and they should describe possible ways of using the program or app in all variants.

Iterativity. As it has been mentioned above, RUP is based on the iterative model. Creators of the RUP recommend at the beginning of every iteration detecting the precedents which should be implemented at the moment. But make sure that each iteration is not very long.

Project cycle. RUP means the use of four stages: inception (the information about the project is gathered, time limits are set, precedents are developed, etc.), designing (optional stage, which contains more detailed description of the precedents, main risks mitigation, etc.), development (development of a final project) and implementation.

Conclusion

Surely, these are not all software development methodologies. There're other ones which sometimes even more suitable on this or that project.

This blog is listed under Development & Implementations and Project & Service Management Community

Post a Comment

Please notify me the replies via email.

Important:
  • We hope the conversations that take place on MyTechLogy.com will be constructive and thought-provoking.
  • To ensure the quality of the discussion, our moderators may review/edit the comments for clarity and relevance.
  • Comments that are promotional, mean-spirited, or off-topic may be deleted per the moderators' judgment.
You may also be interested in
Awards & Accolades for MyTechLogy
Winner of
REDHERRING
Top 100 Asia
Finalist at SiTF Awards 2014 under the category Best Social & Community Product
Finalist at HR Vendor of the Year 2015 Awards under the category Best Learning Management System
Finalist at HR Vendor of the Year 2015 Awards under the category Best Talent Management Software
Hidden Image Url

Back to Top