"
System-level software product development - management and technology
"
Get up early in the morning, the first quarter is the lecture of Zhu Zhu.
But I have listened to half a day to find that I misunderstood the topic of the speech t_t.
I thought that the system level of the system here is the underlying software of the operating system level like the server software.
It was later found that Zhu SIR said that the software applied to the company's application platform.
......
..........
This is clearly the application software! Most more enterprise-class applications, why are you called system level software @ _ @
The lecture is quietly ended during my head chaos, I only remember three points: (^ _ ^;)
First, leaving the space of the employee to avoid outstanding employees to hop from the unopened development.
Second, demand is determined by the support department and market sector. (My understanding: It is actually close to customers as much as possible)
Third, the improvement of the review: I will submit the reviewed object before reviewing the review; the review will be collected before the review, and the high-level issues are only discussed, and the evaluation process is short and delicate.
By the way, Zhu SIR gives an organization of a project group. It is a simple way to divide by:
Project Manager ------ Product Manager
| - ----------------------- QC
| _________________________
| | | | |
Development team leader test team leader supports team leader
| | | | |
Development team leader test team support group
Personally feel this model does not apply to large software development. According to my experience, you can use the following ways to organize:
Project Manager ------ Product Manager
| _________________________________________________
| | | | | | |
| Function a Group Length Function B Group Length Function C Small Function D Group Length
| | | | | | |
Development team leader ---- A function developer --- Function developer --- function developer --- function developer
Testing team leader ---- A function tester --- function tester - C function tester --- function tester
Supporting team leader ---- A function support personnel --- function support personnel --- function support staff --- function support staff
QC team leader ------ A function QC personnel ---- B function QC personnel ---- C function QC personnel ----- D function QC personnel
According to the group length of functional division (A / B / C / D), the functional guidance, work assignment, results check, progress, FOLLOW, etc.
According to the team leader of functional division (development / test / support / QC), the responsible person-in-person-person-assignment - personnel scheduling, skill training, work alphabet, etc.
In this way, the two team leaders have a firm matrix to form a strong matrix to manage the development of large projects.
"
The confusion and improvement of use case practice
"
Ukibin made a wonderful lecture on Usecase. Haha, earn! Lucky ~~ ♪
Especially SIR has clarified the nature of UseCase: It is a scene and step to organize demand.
It is both a communication form (process) and an organizational structure (result).
Usecase is adapted to express most of the functional needs.
Usecase's applicable environment is:
First, have a more complex peripheral environment
Second, the interaction between the system and the peripheral environment consists of several typical scenes.
Usecase is not applicable is:
First, the peripheral environment is simple (there is no need) II. Typical scenes are not clear, there is a large number of possible path combinations, such as IDE operations (cannot be expressed)
Usecase is to organize demand and achieve clear effects.
To divide Usecase from the user's interests (rather than action),
Usecase is gradually supplemented and refined with the understanding of demand. If the user has no meticulous ideas, don't join your own speculation without authorization.
At the same time mentioned a misunderstanding: a lot of people analyze the system, and then do usecase.
At this time, the target of UseCase is back in. It is not to express your own ideas with usecase, but use UseCase to get the user's ideas.
Demand and design correspond to the layer of step.
Later, someone asked such as SIR why the use ofECase map is simple. You Sir's answer I think is not very clear.
Oh, according to my point of view, the first thing to clarify is that the usecase map is not usecase.
Usecase is usually defined using the Usecase table (executor, preamp, main successful scene, extension ...).
The usecase map is drawing the Actor and UseCase to study the relationship between them, and confirm that the problem domains represented by these usecases are not to meet the customer's goals, is it closed (missed).
Therefore, the usecase diagram is simple, and the information it comes is not a lot.
But Usecase itself needs to be meticulous. This complex hidden in the Usecase form.
Second, it is necessary to clarify the input data as a subsequent stage is Usecase instead of the usecase.
Program design, writing help, making user manuals, implement function testing requires Usecase as input, and the Usecase map of the outline is not much value for them.
"
Want to be a thousand miles, more on the next level - build a mature open web application framework, build a strong J2EE enterprise application system
"
This is a speech on the architecture of Fu Jintao.
He first analyzed the characteristics of J2EE companies and applications, then listed some special issues, and then entered Framework.
He puts Framework than the foundation of the company, and lists the advantages of the web application framework:
1. Improve production efficiency by reuse
2, reduce the threshold of development
3. Use mature architecture to reduce development risks
4, provide maintenanceability
5, can also make unified planning, reduce information islands, improve the integration
The development process of layered technology is then analyzed: JSP -> JSP Servlet -> MVC
Then talk about a probably frame: display layer -> interactive layer -> application layer -> domain layer -> resource access layer -> resources.
"
The choice of the fork - the technical breakthrough direction of the software industry in the past night
"
This lecture is very interesting. It is said that Mako said, but the manuscript is Song Xinglie (this article on the 12 period servants) huh, this is another MDA article. First, the horse SIR proposed that the software industry faces the challenge of adapting to technological changes and demand. This is both a direction and a standard of inspection. Then point out that the separation model and the implementation are the key to greet the challenge. Also introduce three models of MDA: PIM, PSM, Code. Then Item of "Moon Myth" in Librox (all software activities include fundamental tasks - to create complex concepts constituting abstract software entities, secondary tasks - expressing these abstract entities using programming languages, map them within space and time limit It is a machine language that indicates that the expression model is the fundamental task. I think there is no new thing so far. Before hot fried MDA, the needs model (night model), design model, and code, three levels of Code are also very popular. The MDA is the most standardized, the horrific part of the most controversial part - the automatic transformation horse SIR between the model has not been discussed. This question is quarreled on the ground, and I also mixed with the foreman and said that MDA (at least in the near future) is unrealistic. The first is that the UML of the DMA is not suitable for precise definition, then software development is not a simple translation process, and finally the automation does not apply to a highly customized environment. Then enter the wonderful part. The horse SIR analyzed 3G language problem. The development of software is only the abstract level of the computing platform so far. 3GL The main means is to use process expression and tell the computing platform for how to do it with instructions. 3GL is a poor language, and their semantics are concentrated instead of business. There are already many dedicated expression languages, such as SQL, such as workflow language (XPDL, BPEL, XLANG, WSFL, BPML, WSCI), rule description language, permission description language, page description language, and more. These languages have been given the specific semantics of the corresponding areas. But the universal model expression language is difficult to implement (UML is not ideal, so the OCL patch will be hit). The current software is a weaker semantic association, an interface, and the API basically cannot provide semantic constraints. Mode, IOC seems to reduce the language dependence, but there is no change in semantic dependence. After listening to this section, I feel the experience value. This thing is similar to the most recent DM (domain model), DDD (domain driver development) seems to have a secret, oh, have a lot of time to study. "
Next generation open source: distributed collaboration and agile practice
"
The Cheng Yong of the gray fox introduced how the development source organization is developed.
Use CVS to perform code management, use XUnit to perform unit testing, use Maven configuration night build, use Wiki to write documentation, use BBS / News to discuss problem exchange, etc. Wait. Of course, these practices have already been widely promoted, and they are not new idea. However, it is not possible to effectively practice these practices.
"
Successful walking out of the death trip - the mystery of software project management
"
ちゃ ちゃ ちゃ ちゃ ちゃ ~ ♪
A new generation of projects management authoritative Zhou Haoyu's lecture on project management lectures.
Unlike other people, Zhou SIR's lecture is full, and it is really doubting that he is a marketing ...
