I've been a developer in various software modalities, including being a Manager of Development, for nearly two decades. I've seen good software development outfits and bad ones, and I'd like to share some of the basics I've learned. You may not agree with all of them, and you may think there should be more, but if you are at the stage where you are interested, at least it can serve as a basis for further study.
You may have seen this semi-humorous outline of the software development process:
1) Order the T-shirts for the Development team
2) Announce availability
3) Write the code
4) Write the manual
5) Hire a Product Manager
6) Spec the software (writing the specs after the code helps to ensure that the software meets the specifications)
8) Test (the customers are a big help here)
9) Identify bugs as potential enhancements
10) Announce the upgrade program
No, that's not it, although it more often than not describes pretty much what happens in a lot of organizations! Now here are the real ones:
1) Requirements Analysis ("Have a Plan")
Extracting the requirements of a software product is the first task in creating it. While the customer (which could be your boss, in some cases) probably believes they know what the software is supposed to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Your first job is to reduce to writing what the software is supposed to do, and put it in detail, and then get "buy off" from the manager(s) and / or customer. This allows you to prevent "Feature creep" -- that nasty bug which prevents much software from ever getting put into production because it's always being "enhanced". Personally, I do not believe in all this XP "Smell the code" and "writing stuff on index cards as you go along". If you have a project that is estimated to take 500 man-hours to complete, then spending 20 to 30 hours of that in the very beginning detailing the requirements and a workable plan is not "too much" time. Unfortunately, many development outfits don't do this, and that's one of the biggest reasons why a lot of software projects fail.
Specification is the task of precisely describing the software to be written, in a rigorous way. There are Fundamental and Technical specifications. This is where you ask the magic question "What are the objects?". Identifying objects is the first step toward a robust, object-oriented product. If you are developing a retail e-commerce web site for example, you would certainly have a "Customer" object, and an "Order" object. But, you would also have other intermediate objects that serve as the "glue" - for example, you might have a CustomerManager object whose task is to enable working with and manipulating Customer objects. It doesn't matter whether it's a diagram on a whiteboard (you can take a picture of it and print it out), or a full-fledged UML Diagram. What's important is that you spell out what the entities are and how they will work together. If you are going to build a building, you need a set of plans. You need plans for building software, too.
3) Software architecture
The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system. This works with the specification, but fleshes out the OS and platform level details of how the software will be built. Once you have decent specifications, you can begin to design interfaces and classes (objects) and describe what they will do.
4) Implementation and Testing
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. Testing is critical to software development success. You should have unit tests as well as more comprehensive "smoke tests", and you should test frequently during the development process. I've seen too much software that gets its only real testing after it's been deployed, usually by the end user. That's NOT the way to develop software.
5) Deliver early and frequently, and put it into production!
Early and frequest delivery of builds allows the developer team to test, as well as the end - user, and can shorten the development process. If you wait a long time between releases to get usable feedback, even if they are alpha or Beta, it can cost a lot more time in having to go back and change things. Depending on the type of project, a two - week release cycle seems to work best, although this can differ depending on the complexity and nature of the project.
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces. But documentation, especially for reusable object-oriented components, is mostly for the benefit of developers.
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. A large percentage of all software engineering work is maintenance, but statistics can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.
8) Resource Allocation
The most expensive part of software development is programmers. I have seen projects where individual devs are literally "sitting around" with nothing to do because there wasn't a well-thought-out resource allocation plan about who would be working on what, and when, and whether they were expected to be available or not. By identifying who will be working on what part of the project, how long it is expected to take them, and when in the timeline they will be expected to be working on it, you can streamline the development process and make it much more productive. That means you'll be able to deliver more, in less time, and at a lower cost.
9) Avoid Redundancy with good Communication and Planning
Use good object-oriented design. If you are going to have a Data Acess layer, have ONE Data Acess layer - one that works for everyone on the team. The worst thing you can find on a software development project is 5 different "data access" layers, each having been written independently of group input by another developer, and each with different ideas and implementation. A good subtitle for this section might be "develop components with reusability in mind". Communication in the group is important for other reasons too. A 15 minute developer team meeting twice a week to go over issues and "what I am working on now" can go a long way toward improving productivity.
10) Have Software Development Rules and a Methodology!
You can find "top ten" lists about software development that are different from these. You can even find "Top 37" lists. You can find Agile, Scrum, Evolutionary, XP. These are the rules that I feel are the most important, based on my experience over the last 2 decades. But the most important rule is this last one - that you should have a set of rules and a methodology, one that works for you and your organization, and -- above all, follow it.