Software Engineering Fundamentals

In a previous software engineering course, while working on a pretend scenario, I had to follow a model of: Requirements, Architectural Design, Implementation, and Testing. First, the requirements were drawn up after talking to a customer. I had to ask the customer what he wanted and write up a document to accurately capture his intentions. I then presented the document to the customer for revision. After all revisions and modifications were completed, I then had the customer accept the requirements document. This helped me, as an engineer, understand what to build for the customer and it helped the customer understand what was going to be built. So the document established a written understanding between software engineer and customer. The next step was to draw up the module design document, which listed and depicted all the different components to the system to be built and all the interactions among those components. This mimicked a blue print like document; saying what plan to follow to build the system. After that document was created the next step is to write actual code, called implementation. After working code was created, the next step was to check the code according to a test plan and then it was ultimately compared to the requirements document to make certain the final product was what the customer intended. Ultimately, the process model used in the class seemed sufficient, however, I realized the process only ran one time through, without multiple iterations. The process used should have more iterations to produce a better product overall. The process was straightforward and easy to follow, and I didn't come across any severe problems while following the process.

Planning Ahead

The most significant and immediate idea I have in mind is the requirements capture. The requirements capture sets the starting point for the entire development of a software product. In a previous course, for planning ahead, I had to communicate with a customer, asking various questions about each of their required features, which made immediate clarifications about the different aspects to their desired software product. The requirements capture marks the starting point, the most critical point, in developing any software product. If the requirements capture is a flop, and major miscommunications were made with the customer then ultimately the product will be a flop, costing great amounts of money. Making changes early on and anticipating future problems, allows for much easier planning in the near future. Specifically, I had to create an automated parking system, and without the requirements at my finger tips, there was no way I could go about building such a system because I wouldn't know where to begin or what features to incorporate.

Modeling

After some thought, I realized the most perfect example for a model in life is a parent. The purpose of a parent is to teach its child how to live in the world. The parent model solves its task by explicitly showing and sometimes telling children how to act. The most obvious designations are the role of child and parent. The main tool used is the parent himself/herself. They use what they know (their brain as a tool), to teach a child. The notations used include hand signals and verbal gestures. Yes, through enough interaction, a parent serves as an easy model to utilize. A parent is simply an older, more mature version than a child. A parent is equipped with certain knowledge, which is passed to the child, serving as a precise model. A parent is what a child one day becomes. The process used to support the model is life experiences and using those to teach a child ("monkey see, monkey do").

Readings

Milestones are concrete measurable events. Milestones mark important dates to remember and important events to perform. They set the stage for what tasks to complete. Milestones adjust to changing schedules to see when things are completed. For process models, they explicitly list the events, which should occur, allowing for planning ahead. For example, extremely important milestones to reach include prototypes, design, implementation, rigorous testing, acceptance test plan, and deployment. Using milestones plans ahead to prevent bad events from occurring and ensuring certain events occur.

Expectations

Standards in the industry

Knowing the various standards in use today will help better prepare you because you'll know what employers will expect from you.

Various tools for developing software

Knowing the tools to use will assist you in developing a better product with ease.

Some tools I have used for designing software include Microsoft Visio, Power Point, TextPad, Paint and Notepad.

Various processes for developing software

Knowing the processes will help you know the right choices to make when designing a system and simply knowing various ones will better prepare you for what employers might expect you to use.

I only know about some of the processes including the waterfall model, incremental, synchronize-and-stabilize etc.

How to handle time constraints - time management

Naturally, employers and customers will expect their projects done at certain times.

I know time management and planning is extremely important. Pert Charts, for example, are used to explicitly show when and what certain tasks will be completed.

How to harness your knowledge into something profitable

With knowing various aspects of software engineering, any student should learn how to successfully utilize those skills for making a living (making money).

Experience is a key ingredient. More experience will give you more knowledge and ultimately allow you to earn more money.

Plan to get a high paying job in the computer field, possibly doing exactly this - software engineering. Yes, software engineering courses should serve useful not only in your academic career, but in your postgraduate career. Learning about software engineering should sufficiently prepare you to enter into the field after graduation.