TOPFAITH UNIVERSITY, MKPATAK
DEPARTMENT OF COMPUTER ENGINEERING
FACULTY OF ENGINEERING
CPE 405: FUNDAMENTALS OF SOFTWARE ENGINEERING
Introduction to Software Engineering Fundamentals
Software engineering is defined as the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the application of
engineering to software. It encompasses a process, a collection of methods (practice) and an array of
tools that allow professionals to build high-quality computer software. It is a systematic approach to
the production of software that takes into account practical cost, schedule, and dependability issues, as
well as the needs of software customers and producers. How this systematic approach is actually
implemented varies dramatically depending on the organization developing the software, the type of
software, and the people involved in the development process.
The bedrock that supports software engineering is a quality focus. The foundation for software
engineering is the process layer. The software engineering process is the glue that holds the
technology layers together and enables rational and timely development of computer software. The
software process forms the basis for management control of software projects and establishes the
context in which technical methods are applied, work products (models, documents, data, reports,
forms, etc.) are produced, milestones established, quality ensured, and change is properly managed.
Software engineering methods provide the technical knowhow for building software.
Methods encompass a broad array of tasks that include communication, requirements analysis, design
modeling, program construction, testing, and support. Software engineering methods rely on a set of
basic principles that govern each area of the technology and include modeling activities and other
descriptive techniques. Software engineering tools provide automated or semi-automated support for
the process and the methods. When tools are integrated so that information created by one tool can be
used by another, a system for the support of software development, called computer-aided software
engineering, is established.
Essential Attributes of a Professional Software
1. Maintainability: Software should be written in such a way so that it can evolve to meet the
changing needs of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
2. Dependability and security: Software dependability includes a range of characteristics including
reliability, security, and safety. Dependable software should not cause physical or economic
damage in the event of system failure. Malicious users should not be able to access or damage the
system.
3. Efficiency: Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilization, etc.
4. Acceptability: Software must be acceptable to the type of users for which it is designed. This
means that it must be understandable, usable, and compatible with other systems that they use.
The Software Process
A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created. An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of rigour with which software engineering is to be applied. An action (e.g.,
architectural design) encompasses a set of tasks that produce a major work product (e.g., an
architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit
test) that produces a tangible outcome.
In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the work (the
software team) to pick and choose the appropriate set of work actions and tasks. The intent is always
to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored
its creation and those who will use it.
The Process Framework
A process framework establishes the foundation for a complete software engineering process
by identifying a small number of framework activities that are applicable to all software projects,
regardless of their size or complexity. In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire software process. A generic process framework
for software engineering encompasses five activities:
1. Communication: Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders). A stakeholder is
anyone who has a stake in the successful outcome of the project, and they include business
managers, end users, software engineers, support people, etc. The intent is to understand
stakeholders’ objectives for the project and to gather requirements that help defi ne software
features and functions.
2. Planning: Any complicated journey can be simplified if a map exists. A software project is a
complicated journey, and the planning activity creates a “map” that helps guide the team as it
makes the journey. The map called a software project plan defines the software engineering work
by describing the technical tasks to be conducted, the risks that are likely, the resources that will
be required, the work products to be produced, and a work schedule.
3. Modeling: A software engineer creates models to better understand software requirements and
the design that will achieve those requirements. This is like a sketch that one creates to understand
the big picture of a thing—what it will look like architecturally, how the constituent parts fit
together, and many other characteristics. If required, you can refine the sketch into greater and
greater detail in an effort to better understand the problem and how you are going to solve it.
4. Construction: What you design must be built. This activity combines code generation (either
manual or automated) and the testing that is required to uncover errors in the code.
5. Deployment: The software (as a complete entity or as a partially completed increment) is
delivered to the customer who evaluates the delivered product and provides feedback based on
the evaluation.
These five generic framework activities can be used during the development of small, simple
programs, the creation of Web applications, and for the engineering of large, complex computer-based
systems. The details of the software process will be quite different in each case, but the framework
activities remain the same.
Software Engineering Process Framework Umbrella Activities
Software engineering process framework activities are complemented by a number of umbrella
activities. In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk. Typical umbrella activities include:
1. Software project tracking and control —allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.
2. Risk management —assesses risks that may affect the outcome of the project or the quality of
the product. Software quality assurance —defi nes and conducts the activities required to ensure
software quality.
3. Technical reviews —assess software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
4. Measurement —defines and collects process, project, and product measures that assist the team
in delivering software that meets stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.
5. Software configuration management —manages the effects of change throughout the software
process.
6. Reusability management —defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
7. Work product preparation and production —encompass the activities required to create work
products such as models, documents, logs, forms, and lists.
The Essence of Software Engineering Practice
The essence of problem solving and the essence of software engineering practice is:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
General Software Engineering Principles
The dictionary defines the word principle as “an important underlying law or assumption
required in a system of thought.” Principles help you establish a mind-set for solid software
engineering practice. David Hooker has proposed seven principles that focus on software engineering
practice as a whole. They are as follows:
The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to its users. All decisions should be
made with this in mind. Before specifying a system requirement, before noting a piece of system
functionality, before determining the hardware platforms or development processes, ask yourself
questions such as: “Does this add real value to the system?” If the answer is no, don’t do it. All other
principles support this one.
The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not a haphazard process. There are many factors to consider in any design
effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily
understood and easily maintained system. This is not to say that features, even internal features, should
be discarded in the name of simplicity. Indeed, the more elegant designs are usually the more simple
ones. Simple also does not mean “quick and dirty.” It often takes a lot of thought and work over
multiple iterations to simplify. The payoff is software that is more maintainable and less error-prone.
The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a project almost
unfailingly ends up being “of two [or more] minds” about itself. Without conceptual integrity, a system
threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws.
Compromising the architectural vision of a software system weakens and will eventually break even
the well-designed systems. Having an empowered architect who can hold the vision and enforce
compliance helps ensure a very successful software project.
The Fourth Principle: What You Produce, Others Will Consume
Seldom is an industrial-strength software system constructed and used in a vacuum. In some
way or other, someone else will use, maintain, document, or otherwise depend on being able to
understand your system. So, always specify, design, and implement knowing someone else will have
to understand what you are doing. The audience for any product of software development is potentially
large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern
for those that must maintain and extend the system. Someone may have to debug the code you write,
and that makes them a user of your code. Making their job easier adds value to the system.
The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. In today's computing environments, where
specifications change on a moment’s notice and hardware platforms are obsolete just a few months
old, software lifetimes are typically measured in months instead of years. However, true “industrial-
strength” software systems must endure far longer. To do this successfully, these systems must be ready
to adapt to these and other changes. Systems that do this successfully are those that have been designed
this way from the start. Never design yourself into a corner. Always ask “what if,” and prepare for all
possible answers by creating systems that solve the general problem, not just the specific one. This
could very possibly lead to the reuse of an entire system.
The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to
accomplish in developing a software system. The reuse of code and designs has been proclaimed as a
major benefit of using object-oriented technologies. However, the return on this investment is not
automatic. To leverage the reuse possibilities that object-oriented [or conventional] programming
provides requires forethought and planning. There are many techniques to realize reuse at every level
of the system development process . . . Planning ahead for reuse reduces the cost and increases the
value of both the reusable components and the systems into which they are incorporated.
The Seventh Principle: Think!
This last Principle is probably the most overlooked. Placing clear, complete thought before
action almost always produces better results. When you think about something, you are more likely to
do it right. You also gain knowledge about how to do it right again. If you do think about something
and still do it wrong, it becomes a valuable experience. A side effect of thinking is learning to recognize
when you don’t know something, at which point you can research the answer. When clear thought has
gone into a system, value comes out. Applying the first six principles requires intense thought, for
which the potential rewards are enormous.
Software Engineering Ethics
Software engineering is carried out within a social and legal framework that limits the freedom
of people working in that area. As a software engineer, you must accept that your job involves wider
responsibilities than simply the application of technical skills. You must also behave in an ethical and
morally responsible way if you are to be respected as a professional engineer. You should uphold
normal standards of honesty and integrity and not use your skills and abilities to behave in a dishonest
way or in a way that will bring disrepute to the software engineering profession.
However, there are areas where standards of acceptable behavior are not bound by laws but by
the more tenuous notion of professional responsibility. Some of these are:
1. Confidentiality: You should normally respect the confidentiality of your employers or clients
irrespective of whether or not a formal confidentiality agreement has been signed.
2. Competence: You should not misrepresent your level of competence. You should not knowingly
accept work that is outside your competence.
3. Intellectual property rights: You should be aware of local laws governing the use of intellectual
property such as patents and copyright. You should be careful to ensure that the intellectual
property of employers and clients is protected.
4. Computer misuse: You should not use your technical skills to misuse other people’s computers.
Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to
extremely serious (dissemination of viruses or other malware).
Software Engineering Code of Ethics and Professional Practice
ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices
PREAMBLE
The short version of the code summarizes aspirations at a high level of the abstraction; the
clauses that are included in the full version give examples and details of how these aspirations change
the way we act as software engineering professionals. Without the aspirations, the details can become
legalistic and tedious; without the details, the aspirations can become high sounding but empty;
together, the aspirations and the details form a cohesive code.
Software engineers shall commit themselves to making the analysis, specification, design,
development, testing and maintenance of software a beneficial and respected profession. In accordance
with their commitment to the health, safety and welfare of the public, software engineers shall adhere
to the following Eight Principles:
1. PUBLIC — Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT — Software engineers shall ensure that their products and related modifications meet
the highest professional standards possible.
4. JUDGMENT — Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and promote
an ethical approach to the management of software development and maintenance.
6. PROFESSION — Software engineers shall advance the integrity and reputation of the profession
consistent with the public interest.
7. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues.
8. SELF — Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.
PRACTICE QUESTIONS
1. Is software engineering applicable when WebApps are built? If so, how might it be modified to
accommodate the unique characteristics of WebApps?
2. As software becomes more pervasive, risks to the public (due to faulty programs) become an
increasingly significant concern. Develop a doomsday but realistic scenario in which the failure
of a computer program could do great harm, either economic or human.
3. Describe a process framework in your own words. When we say that framework activities are
applicable to all projects, does this mean that the same work tasks are applied for all projects,
regardless of size and complexity? Explain.
4. Umbrella activities occur throughout the software process. Do you think they are applied evenly
across the process, or are some concentrated in one or more framework activities? What are the
four important attributes that all professional software should have?
5. Apart from the challenges of heterogeneity, business and social change, and trust and security,
identify other problems and challenges that software engineering is likely to face in the 21st
century (Hint: think about the environment).
6. For each of the clauses in the ACM/IEEE Code of Ethics, suggest an appropriate example that
illustrates that clause.
7. To help counter terrorism, many countries are planning or have developed computer systems that
track large numbers of their citizens and their actions. Clearly this has privacy implications.
Discuss the ethics of working on the development of this type of system.
