SOE-like software development process and toolset

In the software development process of state-owned enterprises and quasi-state-owned enterprises, how to control the quality is a big problem, because there are too many things under the table to consider. The agile development process is difficult to implement in a state-owned enterprise, which is a foreign language.

Let’s talk about the conclusion first. I use ICONIX in the development process. The

ICONIX process is usecase driven, but it is lighter than RUP. Provides adequate requirements and design documentation compared to agile methods. At the same time, over-analysis is avoided. The ICONIX process uses only four UML diagrams (usecase, class, sequence, robustness analysis).
Robustness analysis is the main difference between ICONUX and other processes. It bridges the gap between analysis and design. Written in the context of a domain model, it minimizes the ambiguity of usecases. ICONIX makes usecases easier to design, test, and evaluate. The following figure is a conceptual diagram of ICONIX.


Why ICONIX process suitable for the development of state-owned enterprise systems? This is because
1. It is difficult for the system to achieve a good iterative model, and it is difficult to develop with an attitude of embracing changes. Businesses pay more attention to SOW, and change is CR;
2. There is a lot of ambiguity in the understanding of business personnel and technical personnel. It can be solved by a BA or a customer representative. The advantage of using ICONIX is that ICONIX is a modeling process based on core logic analysis and design;
3. The ICONIX process can be used without tailoring, avoiding the lack of enterprise process engineers and the tailoring process trouble (like RUP).
4. The test model of the V model is more conducive to the control of the test.

Of course, the use of software processes has a lot of related content, such as some concepts and processes of CMM/CMMI should be combined.


The software process does not guarantee the completion of system development according to time and quality. This requires some automated integrated toolsets to help solve this problem. This part refers to some agile methods. The main toolsets are (based on JAVA development)
Issue Tracking and Project management: redmine
Version control: Subversion
Continuous integration: Hudson
Unit testing: testNG
Test coverage: cobertura
Code inspection: findBugs, pmd, checkstyle, cpd
Integration testing: selenium
Stress testing: jmeter

The following are explained separately:
redmine is developed based on ROR and provides Sufficient project Issue Tracking and management functions, integration functions such as Subversion, etc., are best used in open source. It's fine if you use the commercial Jira too. Trac is too difficult to match, mantis is just a tool for bug tracking.

Hudson is a continuous integration tool. I used CC, but Hudson is still easy to use.
hudson will generate a daily build version every day; compile the following source code in 10 minutes, and send errors to the relevant developers; do a report every day, including unit test, integrated report of findbugs/pmd/checkstyle/cpd/cobertura (using jcreport integration https://github.com/jCoderZ/fawkez/wiki/JcReport ), do a selenium test, etc. Deployment can also be done manually/automatically.

Subversion It is a centralized VCS. I am very interested in git. After all, it is a masterpiece of linus. However, the concept of git is open, without permission control, and is not suitable for enterprise application development.

testNG and junit are also OK, but I will focus on unit testing of associations, and the concept of junit is isolation. In addition, unit testing may be disgusting to programmers, but writing or not writing unit testing and the quality of unit testing are important indicators for me to measure the ability of a developer. BUGs affected by system changes without writing unit testing may be devolved to QA tests. , the ability of integration testing is still insufficient in this regard.

cobertura , a framework for java unit test coverage, integrates well with testNG. The same function also has emma, cobertura is suitable for complete reports, if it is used by eclipse, eclemma is good. The problem with using test coverage is that you can't let the unit test fool it, and I'm after 90% coverage. Actually, 70% is pretty good.

findBugs, pmd, checkstyle, cpd :
fingbugs checks javabytecode based on bug patterns, such as NullPointer
pmd checks source files, if variables are not used,
checkstyle is mainly coding specifications, such as javadoc specifications, etc.
cpd is mainly copy paste

selenium : if commercial can be used Qtp
selenium can record web scripts, and now the support for js is also very strong. Automated integration testing is just an add-on, don't have high expectations.

jmeter For some functions of stress testing, such as databases, web applications, etc., due to the complexity of the system, in some scenarios, the program for stress testing will be implemented by itself. jmeter is generally not integrated into hudson because its behavior may cause instability in the hudson system.


Conclusion: Although working in this way can effectively improve the quality of software development, the increase in development costs is not large, but there are very few projects that can really do this, and sometimes it is really helpless.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327048027&siteId=291194637