[Software] C.1 Software and Software Engineering

📋 This is my note-taking from what I learned in the class “Software Engineering Fundamentals - COMP 120-002”

Software

Nature of Software – Defining Software

Software is:

• Instructions (computer programs) that when executed provide desired features, function, and performance;
• Data structures that enable the programs to adequately manipulate information.
• Documentation that describes the operation and use of the programs.

What is Software? 💡

1. Instructions (computer programs) that when executed provide desired features, function, and performance.
2. Data Structures that enable the programs to adequately manipulate information.
3. Documentation that describes the operation and use of the programs.

• Software is developed or engineered it is not manufactured in the classical sense.
• It is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware.
• Software doesn’t “wear out“ but is does deteriorate.
• Although the industry is moving toward component-based construction, most software continues to be custom-built.

Hardware failure “bathtub” curve 💡

Failure rate for hardware with time - Bath tub - Wears out

• This graph shows the rate of failure as a function of time for hardware.
• The “bathtub curve” indicates that hardware exhibits relatively high failure rates early in its life, often attributable to design or manufacturing defects.
• Once the defects are corrected, the failure rate drops to a constant level.
• As time passes, however, the failure rate rises again as hardware components suffer from physical and environmental stresses.
• The hardware begins to wear out.

Software failure curve: Wear versus Deterioration 💡

Failure rate for software with time - We have spikes of failure when a change is introduced, with times, bugs, errors, are fixed. It deteriorates.

• Software is not susceptible to the same stresses that causes hardware to wear out.
• In theory, the failure rate curve for software should look like the “idealized curve” shown above.
• Undiscovered errors will cause high failure rates early in the life of a program.
• However, these are corrected and the curve flattens as shown.
• The idealized curve is a gross oversimplification of actual failure models for software.
• However, even though software does not wear out, it does deteriorate.
• This is shown with the actual curve in the above graph.
• During its life, software will change, and as changes are made, errors are introduced.
• The spike in the failure rate curve coincides with when a change was made.
• But before the the curve returns to the original steady-state failure rate, other changes are requested and the curve spikes again.
• The cumulative impact of these failure spikes causes the minimum failure rate level to rise - this is the deterioration of the software as it changes.

Software Application Domains

Today, there are seven broad categories of computer software that each have their own challenges for software engineers.

System software

• A collection of programs written to service other programs.
• Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate, information structures.
• Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data.

Application software

• Stand-alone programs that solve a specific business need.
• Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

Engineering/Scientific software

• A broad array of “number crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology.

Embedded software

• Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself.
• Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

Product-line software

• Composed of reusable components and designed to provide specific capabilities for use by many different customers.
• It may focus on a limited an esoteric marketplace (e.g., inventory control products) or attempt to address the mass consumer market.

Web/Mobile applications

• This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices.

Artificial Intelligence software (robotics, neural nets, game playing)

• Makes use of heuristics to solve complex problems that are not amenable to regular computation or straightforward analysis.
• Applications within this area include robotics, decision-making systems, pattern recognition (image and voice), machine learning, theorem proving, and game playing.

Legacy Software

Hundreds of thousands of computer fall into one of the seven broad application domains described above, and some of them are state-of-the-art. But some programs are much, much older, some even decades old and still in use today.

Legacy software has been of concern since the 1960s. It has been described as software that was developed decades ago and continually modified to meet changes in business requirements and computing platforms.

The ongoing changes in legacy software to maintain its continual use create a side effect of poor quality. Legacy systems have many issues including, but not limited to, inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never achieve, and poorly managed change history. And yet these systems often support “core functions and are indispensable to the business.”

Most places choose not to do anything about their legacy systems so long as it still meets the needs of its users and runs reliably - “if isn’t broken, don’t fix it.” However, legacy systems must eventually evolve for one or more of the following reasons:

Why must software change?:

• Software must be “adapted” to meet the needs of new computing environments or technology.
• Software must be “enhanced” to implement new business requirements.
• Software must be “extended to make it interoperable” with other more modern systems or databases.
• Software must be “re-architected” to make it viable within a network environment.

When one of these modes of evolution occur, a legacy system must be reengineered so that it remains viable in the future, or “future-proofed”.

Web Apps

Modern WebApps are much more than hypertext files with a few pictures.

WebApps are augmented with tools like XML and Java to allow Web engineers including interactive computing capability.

WebApps may standalone capability to end users or may be integrated with corporate databases and business applications.

Semantic web technologies (Web 3.0) have evolved into sophisticated corporate and consumer applications that encompass semantic databases that require web linking, flexible data representation, and application programmer interfaces (API’s) for access.

The aesthetic nature of the content remains an important determinant of the quality of a WebApp.

Mobile Apps

• Reside on mobile platforms such as cell phones or tablets.
• Contain user interfaces that take both device characteristics and location attributes.
• Often provide access to a combination of web-based resources and local device processing and storage capabilities.
• Provide persistent storage capabilities within the platform.

A “mobile web application” allows a mobile device to access to web-based content using a browser designed to accommodate the strengths and weaknesses of the mobile platform.

A “mobile app” can gain direct access to the hardware found on the device to provide local processing and storage capabilities.

As time passes these differences will become blurred.

Cloud Computing

“Cloud computing” provides distributed data storage and processing resources to networked computing devices.

Computing resources reside outside the cloud and have access to a variety of resources inside the cloud.

Cloud computing requires developing an architecture containing both frontend and backend services.

Frontend services include the client devices and application software to allow access.

Backend services include servers, data storage, and server-resident applications.

Cloud architectures can be segmented to restrict access to private data.

Product Line Software

“Product line software” is a set of software-intensive systems that share a common set of features and satisfy the needs of a particular market.

These software products are developed using the same application and data architectures using a common core of reusable software components.

A software product line shares a set of assets that include “requirements, architecture, design patterns, reusable components, test cases,” and other work products.

A software product line allow in the development of many products that are engineered by capitalizing on the commonality among all products within the product line.

Characteristics of WebApps - II

• “Data driven” — The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user.
• “Content sensitive” — The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp.
• “Continuous evolution” – Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously.
• “Immediacy” — Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks.
• “Security” — Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application.
• “Aesthetics” — An undeniable part of the appeal of a WebApp is its look and feel.

---

---

Software Engineering

Software Engineering 💡

Some realities about building software to meet the challenges of the twenty-first century:

• A concerted effort should be made to understand the problem before a software solution is developed.
• Design has become a pivotal activity.
• Software should exhibit high quality.
• Software should be maintainable.

The seminal definition:

[Software engineering is] the establishment and use of “sound engineering principles” in order to obtain “economically” software that is “reliable and works efficiently” on “real machines”.

The IEEE definition:

[Software engineering is] the application of a “systematic, disciplined, quantifiable approach” to the “development, operation, and maintenance” of software; that is, the application of engineering to software.

Software Engineering Layers

A Quality Focus

Any engineering approach (including software engineering) must rest on an organizational commitment to quality.

You may have heard of total quality management (TQM) or Six Sigma, and similar philosophies that foster a culture of continuous process improvement.

It is this culture that ultimately leads to more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus.

Process Model

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. Process defines a framework that must be established for effective delivery of software engineering technology.

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 are established, quality is ensured, and change is properly

Methods

Software engineering methods provide the technical how-tos for building software.

Methods encompass a broad array of tasks that include communication, requirement 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.

Tools

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 of the support of software development, called computer-aided software engineering, is established.

The Process Framework Activities 💡

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.

A generic process framework for software engineering encompasses five activities.

Communication

Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders). The intent is to understand stakeholders’ objectives for the project and to gather requirements that help define software features and functions.

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.

Modeling

Regardless of your profession, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.

• Analysis of requirements
• Design

Construction

This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

• Code generation
• Testing

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.

Umbrella Activities 💡

Framework activities are complemented with Umbrella activities.

Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a soft-ware project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include:

• “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.

• “Risk management” — assesses risks that may affect the outcome of the project or the quality of the product.

• “Software quality assurance” — defines and conducts the activities required to ensure software quality.

• “Technical reviews” — assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.

• “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.

• “Software configuration management” — manages the effects of change throughout the software process.

• “Reusability management” — defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.

• “Work product preparation and production” — encompasses the activities required to create work products such as models, documents, logs, forms, and lists.

Process Difference Requiring Adaptation

• Overall flow of activities, actions, and tasks and the interdependencies among them.
• Degree to which actions and tasks are defined within each framework activity.
• Degree to which work products are identified and required.
• Manner which quality assurance activities are applied.
• Manner in which project tracking and control activities are applied.
• Overall degree of detail and rigor with which the process is described.
• Degree to which the customer and other stakeholders are involved with the project.
• Level of autonomy given to the software team.
• Degree to which team organization and roles are prescribed.

The Essence of Software Engineering Practice 💡

George Polya - Essence of SE practice

In the book How to Solve It, written before modern computers existing, Polya wrote:

1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine result for accuracy (testing & quality assurance).

Understand the Problem

• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, and features are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?

Plan a Solution

• Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

Carry out the Plan

• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?

Examine the Result

• Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?
• Does the solution produce results, that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?

Hooker’s General Principles 💡

1. The Reason It All Exists – provide value to users.
2. KISS (Keep It Simple, Stupid!) – design simple as it can be.
3. Maintain the Vision – clear vision is essential.
4. What You Produce, Others Will Consume.
5. Be Open to the Future - do not design yourself into a corner.
6. Plan Ahead for Reuse – reduces cost and increases value.
7. Think! – placing thought before action produce results.

How it all Starts – SafeHome Begins

Every software project is precipitated by some business need:

• The need to correct a defect in an existing application;
• The need to the need to adapt a ‘legacy system’ to a changing business environment;
• The need to extend the functions and features of an existing application, or
• The need to create a new product, service, or system.

---

Back to Top

See other articles in Category Software