Software Engineering

I like the definition of Software Engineering at Wiki: Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. If you ask one hundred Software Engineers about the scope of software engineering, you might get 100 different answers. In my view, there are really 2 subcategories only:

1. How to present the software design? In other words, Software Modeling, or more concrete word, graphical representation of software blueprint;
2. How to make software engineers collaborate towards the same goal (instead of work against each other, don’t laugh, it happens). Or in other words, how to manage the space or time diversity of a software product, and how to break down the complexity of a software/firmware product (modularization).

The era that a single software hero creates an entire industry successed software product has gone. OK! Don’t argue with me that Linus Torvaldes is maintaining the Linux kernel by himself (still with other people’s help). There is only one Linus Torvaldes in the world, you and I are not as smart as him, I am talking about what’s happening in the industry. The industry trend is really how to manufacture software product through collaboration effort of teams made up of normal people, and located across the globe. Software architects and managers should really concern on making software implementation work and resource allocation more predictable. Has been saying that, they should really think about the above 2 Software Engineering questions.

In my opinion, these 2 questions could be expanded to a lot more questions as below. There are tons of books to discuss these questions. However, I merely list the possible questions for reference.

How to present the software design?

1. What is the most efficient way to model a software system? Why this modeling important?
2. What is the suitable tool for software modeling in your project?
3. Is it possible to auto-generate the code or code stub?
4. How to bridge the gap between business requirement, software design, implementation, testing and support? In other words, what is the best way to represent the software requirements?
5. How to control the auto-generation overhead? If the auto-code generation overhead is not acceptable, is there anyway to do it manually, retain the graphical design and write the efficient code manually?
6. Is it possible to test before implementation? Sounds weird? However, it is possible to just test code stub, which will be very useful for design validation at the early stage.

How to make software work predictable?

1. How to design software components or improve the modularity of existing codebase?
2. How to control the time variation? This comes to the topic of Software Verstion Control Management.
3. How to control the space variation? In other words, software reuse or variation based software reuse.
4. How to estimate software effort based on software components?
5. How to predict the software productivity based on Engineers capability and component complexity? Subsequently, how to make a realistic software schedule.
6. How to make test more effective? In other words, how to setup an effective test environment which is capable of generating many corner cases. How to quantify and improve test coverage?
7. How to make new Engineers (or all Engineers) easy to ramp up on one project?
8. How to break down the product scope and make project risk more predictable?