Software Engineering discussion

Integration processes and tools and dedicated personnel are an essential part of medium/large projects, but I have not seen much written about this topic before. This brief introduction is nice, especially the pointers to other resources.

I favor the T integration approach, combined with the feature integration approach. In combining these ideas, you can get a little tower of code working, kind of like a backbone, and then incrementally add to it based on feature units. This seems most compatible with the focus in project management and testing, which are usually feature-centric as well.

Your suggested approach makes alot of sense.

I never liked the top-down or bottom-up approaches very much. It was nice that this chapter gave some other options too.

I think my team at work would benefit from having a full-time integration and test engineer. To me integration is never boring task, and I can have the same fun doing integration as doing design and coding, but certainly problem solving nature of doing this task is different, but also very challenging and interesting. It is interesting because this person gets to see different pieces of software working together before anyone else. Challenging because this person has to know many details of each piece of software, overall system operation, have a good knowledge of software engineering, deal with different people coding habits, and have very good communication skills, and many others.

To me the best approach doing integration is probably the same as to others: having underlying software infrastructure including generic utilities ready for adding new modules or processes, and then integrating these pieces one by one, solving problems between these pieces before proceeding to integrating other pieces.

Good chapter. Interesting example with Windows 2000…For me it’s hard to imagine how these projects being managed. Almost the same as thinking about higher dimensional space and time:) jk