Introduction to Software Engineering

A legacy system is an old computer system that continues to be used because it still functions according to the users’ needs, even though newer technology or more efficient methods of performing a task are now available. Convenience is mostly why clients follow the “old is gold” trend. What does this have to do with software engineering tho? For starters, software engineering has everything to do with theories, methods, and tools for developing professional software. However, around 60% of software costs are development costs, while the rest are testing costs. Hence, that expenditure is mainly why the lifetime of software systems is expected to exceed 10 years (if not more), turning them into legacies.

Introduction to Software Engineering
Software costs dominate computer system costs, which is why [cost-effective] software development with good attributes like maintainability, dependability & security, efficiency, and acceptability is important. Hence, it is good to remember that reusing old software when appropriate is preferable than writing new software from scratch. Software products come in two forms: Generic products, which are stand-alone systems sold to the public with rights fully owned by the developer and customized products, which are software commissioned by a specific client, who will be granted sole rights to the software. Generally, software engineering involves 4 activities:

  1. Specification: engineers & customers define how the software is to be produced under specified constraints.
  2. Development: software is designed and programmed.
  3. Validation: software is checked to ensure there are no faults and that it meets the customers’ requirements.
  4. Evolution: software is altered to adapt to current changes & market trends.

On a different note, one thing I noticed is that rookie programmers tend to interchange the concept of a program and a software unintentionally. Before taking this unit, I too was guilty of that; mainly because I didn’t know the different between the two:

PROGRAM VS. SOFTWARE PRODUCT
Program Software
– Small in size with limited functionality. – Extremely large with a lot of features.
– Programmer himself is the sole user. – Most users aren’t involved in development.
– Single developer aka the programmer. – Large number of developers involved.
– User interface is not very significant. – User interface is carefully implemented.
– Very little or no documentation. – Well documented.
– Following programmers’ individual style. – Following software engineering principles.

Software engineering reduces programming complexity via following two techniques: abstraction and decomposition. The main purpose of abstraction is to omit irrelevant details in order to focus on relevant ones and suppress aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details are taken into consideration to solve the next lower level abstraction. On the other hand, decomposition focuses on dividing a complex problem into several smaller parts and then solving each smaller part one by one. A good decomposition of a problem is said to minimize interactions among various components.

One more thing to keep in mind is that software engineering ethics is more than just the mere application of technical skills, but rather the practice of principles that are morally correct, such as: respecting confidentiality, being competent, adhering to intellectual property rights, and correctly using computers. You may checkout the ACM/IEEE code of ethics for more information.

Challenges & Evolution
The main challenge here, lies in the current software crisis which is driven by the increased expenditure on software products. Today, organizations spend larger portions of their budget on software, and yet are faced with problems like:

  1. Software products are difficult to alter, debug, and enhance.
  2. Resources are used non-optimally.
  3. Products often fail to meet user requirements.
  4. Products are unreliable, frequently crash, and are often delivered late.

These problems can only be battled with spreading awareness of software engineering practices among engineers, along with more advancements within the software engineering discipline itself. However, doing something about the factors contributing to this crisis is also important. Those factors are larger problem sizes, lack of adequate training in software engineering, increasing skill shortage, and low productivity improvements.

Like what Søren Kierkegaard once said, “Life can only be understood backwards; but it must be lived forwards.” The same concept applies to software engineering. It is important to know past failures, successes, and major milestones in order to utilize current technologies for the betterment of the software engineering discipline.

EVOLUTION OF SOFTWARE DESIGN TECHNIQUES 
1950s Most programs were written in assembly language, where programmers followed exploratory programming, which was programming based on a developers’ individual style or intuition.
Early 1960s  Languages like FORTRAN, ALGOL, and COBOL were introduced. Exploratory programming style was starting to be insufficient as programmers had a hard time writing cost-effective and correct programs and understanding & maintaining programs written by others.
Late
1960s
It was found that the “GOTO” statement was harmful and the main reason why the control structure of a program is complicated and messy. Later structured programming was discovered; it uses 3 types of program constructs: selection, sequence, and iteration.
Late 1970s Data structure-oriented design became the next hit, where programmers were encouraged to pay more attention to the design of a programs’ data structure rather than to the design of its control structure.
1980s Object-oriented design was introduced and is now the latest and most widely used technique.

Lastly, I am pretty much done. Please bear in mind, that this entire post serves as an introduction to the unit. I will leave you now with the core principles of software practice, have a great day!

  1. Software exists to provide value to its users.
  2. Keep it simple stupid (KISS).
  3. Clear vision is important to the success of any software project.
  4. Always specify, design, and implement knowing that someone else will have to understand what you have done.
  5. Be open to future changes and technological advancements; don’t code yourself into a corner.
  6. Plan ahead for reuse as that lowers cost and increases the value of both the reusable components and the systems that require them.

Checklist aka Things you should [kinda] know after reading this post:

  • Software Crisis & Software Engineering Origin
  • Challenges to Software Engineering
  • Professional Conduct & Code of Ethics
  • System Attributes & Qualities

References:
ITT KHARAGPUR. Software Engineering. Retrieved from nptel.ac.in.
Sommerville, Ian. Software Engineering. Retrieved from SlideShare.

Background Story: Hey, I’m Yasmin, a soon-to-be junior CS Major at UoPeople with 80 credit hours down. I will be using my blog as a platform to help me study and share what I learn on a weekly basis with my fellow classmates and readers. Follow the Studying CS at UoPeople section for weekly blog posts published every Friday.  Please note, this series will not interfere with the weekly Monday posts. Thanks for reading. Cheers!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s