295
CHAPTER
Epilogue and Some
Contemporary Issues
14
In this text, we have discussed most of the main topics of software engineer-
ing. It has been our intent to provide a broad introduction to the subject and
yet to be concise enough to allow the material to be covered within a semes-
ter time frame of 15 to 16 weeks. Although many “favorite” topics in software
engineering may not be included, readers will be directed to the Suggested
Readings section at the end of each chapter.
It is clear that the main topics of today will also evolve and change. What
is now considered new and exciting in software engineering may be old and
irrelevant in a few years. However, there are some topics that will remain
important, and we hope we have captured those. This book emphasizes the
need for software engineering by starting with the implementation prob-
lem of a program by a single person and by demonstrating the tremendous
increase in complexity when the problem is changed to building a system
such as a commercial payroll system. The traditional software engineering
activities of requirements analysis, designing, implementation, testing, and
system integration are discussed with mostly large and complex systems
in mind. The supporting activities of configuration management, process
management, and project management are also presented with large teams
and complex systems in mind. There is recognition that not all projects,
especially those that are small, need the same process or the same manage-
ment approach or even the same set of activities. For example, we expect a
continued pendulum swing toward Agile processes in the next few years (see
Chapter 5). There are many topics that need to be covered in much more
91998_CH14_Tsui.indd 295 1/10/13 12:14:36 PM
detail in a follow-on course. Each of the software engineering activities that contributes
directly to the development of the product—such as requirements gathering, analysis,
testing, or designing—deserves a complete course.
With software becoming a ubiquitous element in the engineering curriculum and in
many other disciplines, topics such as reuse, copyright, ownership, certification, and eth-
ics are also gaining our industry’s attention. These are topics future software engineers
will need to wrestle with. We gave only a cursory coverage to these in Chapter 3. As
quality continues to be a recurring theme in software engineering, it should be a natural
part of the basic fabric of software engineering. As such, we have pointed to quality as a
motivator to perform activities such as design and implementation as thoroughly and as
well as possible. Thus, we did not dedicate a separate chapter to quality but do realize its
ongoing significance in our industry.
A growing and an important area related to quality is the notion of measurement
and metrics. It is very difficult to know if we are gaining ground in software engineering
unless we can measure some of the characteristics of the software product, software pro-
cess, software methodology, and software management. This is a fairly important topic,
and we have covered only a part of it in Chapter 8, where design characteristics and the
associated metrics are discussed. We expect more emphasis will be placed in this area as
our industry starts to ask more critical questions: How do we know a design is complete
and good? What is the basis for making release decisions?
Most of the large commercial software products undergo multiple versions and usu-
ally last many years. The area of maintenance and support will continue to be a grow-
ing area. For many software engineers, it is not the case that their projects will dutifully
march through the traditional software life cycle depicted in this text. Many software
engineers will be engaged in developing and maintaining existing systems. They may be
engaged in service and support of customers much more than in developing a complete,
new system. This area, covered in Chapter 12, will require more emphasis in the future as
software service businesses continue to expand and grow.
Finally, the Internet and related new software tools have placed additional opportuni-
ties and constraints on our field. As mission-critical applications become Internet-based
and e-commerce continues to grow, we need to be much more aware of the issues
related to security, integrity, and recovery. We will provide a short definition and discus-
sion of security in the following section. We did not cover the other issues here but expect
that it will be a growing field that future software engineers will have to keep an eye on.
The topic of user-interface characteristics (as discussed in Chapters 7 and 8) is evolving
quickly as new tools such as Macromedia’s Dreamweaver and Flash gain popularity. The
software engineers interested in this area would need to include skills and knowledge
from fine arts and communications disciplines in addition to their technology skills.
Software engineering was born during an era when software project schedules
were regularly missed and cost overruns were constantly recurring. Since then we have
learned to place more effort in planning and in controlling projects. Newer and better
techniques and methodologies have been introduced. Productivity-related tools helped
us not only reduce complexity and effort but also improve on product and process qual-
296 Chapter 14 Epilogue and Some Contemporary Issues
91998_CH14_Tsui.indd 296 1/10/13 12:14:36 PM
ity. This field is more disciplined today, and we expect it to evolve into one that will have
better defined and substantiated laws and principles for all of us to follow.
In the next few sections we will delineate some of the more recent concerns and
progresses in software engineering. The topics covered, by definition, are the authors’
choices and thus reflect some of the authors’ biases.
14.1 Security and Software Engineering
Today, the functionalities provided by software applications are moving to the Internet
as online business services, and Service Oriented Architecture (SOA) is rapidly gain-
ing popularity. (See Finch [2006] and Zimmermann [2005] in the Suggested Readings
section.) As computer networks have become more pervasive—almost every software
system is connected one way or another to the Internet—the opportunities for mali-
cious users to exploit errors to gain unauthorized access to a system has also increased
tremendously. At any moment, there is a high probability that somebody is thinking of
how to hack into a system. As professionals, we need to design software to withstand
these attacks. Security issues also spawn discussions in other related topics such as pri-
vacy and trust.
Although there are particular techniques to make software more secure, most soft-
ware security–related problems are really software defects that can be avoided or fixed
with standard software engineering techniques. In fact, most software security problems,
such as buffer overruns and SQL and HTML injection, may be categorized as input valida-
tion errors.
One issue that compounds security problems is that most modern applications are
not completely written in statically typed languages, but rather a combination of stati-
cally and dynamically typed languages. Most web applications are developed in HTML
that is then interpreted by a web browser. Also, most applications send SQL strings to a
DBMS for interpretation. We need to make sure that the inputs we are processing do not
change meaning when interpreted by a DBMS or a browser, and we cannot rely on static
typing to help us; we need to make sure that every input is valid.
Following the traditional patterns in computing, researchers are actively exploring the
theoretical aspects of computer security, and practitioners are incorporating these tech-
niques into programming. However, we need to popularize the inclusion of security prac-
tices into software development processes. We are working on theory and coding practices
but have yet to engineer secure systems. It will take time before security thinking becomes
pervasive and most development processes incorporate security as one of its most impor-
tant elements. Many leading companies such as Microsoft, IBM, and others have started to
embrace development life cycles that include security as an integral part of the cycle.
See Howard and Lipner (2006) in the Suggested Readings section for a description
on Secure Development Life Cycles. Also, BSI (2009), an initiative of the National Cyber
Security Division (NCSD) of the U.S. Homeland Security in conjunction with the Software
Engineering Institute (SEI), has developed processes and technologies for software
developers to utilize and incorporate in their development life cycle.
14.1 Security and Software Engineering
297
91998_CH14_Tsui.indd 297 1/10/13 12:14:36 PM
14.2 Reverse Engineering and Software Obfuscation
With the advent of cloud computing and software as a service model and its increasing
popularity, application software are frequently moved across the Internet. Application
software code is often exposed, and the opportunity for sabotage or reverse engineer-
ing is much higher. In contrast to the earlier desire in software engineering to simplify
software to improve on complexity and quality, software engineers are now experiment-
ing with software obfuscation to further increase complexity to diminish human under-
standability. Software obfuscation is a new area in software engineering where the goal
is to make reverse engineering uneconomical for the perpetrators. It is achieved through
some form of transformation to the original software, preserving the functionality but
altering the source code.
It has been shown that a “generalized black-box” software obfuscator is not pos-
sible (Barak et al. 2001). However, there are still many practical software obfuscation
techniques worth considering for slowing down reverse engineering. Some of the more
popular ones include the following categories of techniques:
n
Lexical obfuscation
n
Data obfuscation
n
Control obfuscation
n
Call-flow obfuscation
As an example, lexical obfuscation has been practiced by many earlier programmers
who purposely named program variables out of context to confuse the readers. The
more the readers were confused, it was thought erroneously, the brighter the author
was. This practice is now deemed bad software engineering, especially for software
understandability, testing, and future maintenance. However, with the recent need for
software protection, this same technique is used for software obfuscation. This tech-
nique is relatively limited and weak. It clearly does not provide sufficient protection.
More sophisticated techniques include data obfuscation and control obfuscation.
Data obfuscation transformation targets the data and the data structures in the program
via complicating the data structure, data operations, and data usage. Popular techniques
include splitting an array structure or modifying the inheritance relationship. Control
obfuscation techniques include the altering of the control flow by inserting irrelevant,
but innocuous, predicates or by harmless reordering of some of the program statements.
While lexical, data, and control obfuscation techniques focus on the micro level, call-flow
obfuscation techniques concentrate on the macro level of control flow across modules.
The effectiveness of software obfuscation techniques may be viewed or measured
in different ways. We may ask (1) how potent the technique is, (2) how resilient the
technique is, (3) how expensive the technique is, or (4) how surreptitious the technique
is. At the moment of this writing, there is no universally agreed upon set of measure-
ment attributes for software obfuscation. Besides software obfuscation, there are other
areas engaged in software prevention techniques, such as watermarking and tamper-
proofing, from malicious perpetrators. Interested readers should consult Collberg
and Thomborson (2002). Other, more recent sample articles on
software obfuscation
by Balachandran and Emmanuel (2011) and Tsui, Duggins, and Karam (2012) are also
included in the Suggested Readings section.
298 Chapter 14 Epilogue and Some Contemporary Issues
91998_CH14_Tsui.indd 298 1/10/13 12:14:36 PM
14.3 Software Validation and Verification Methodologies and
Tools
In this section we discuss some of the recent progress that has been made in the area
of software validation and verification. Validation implies that the software has been
shown to be acceptable to the customer and is correct, while verification implies that
the software is properly developed from the requirements and abides to the specifica-
tions given. Both development process and test process experts have been investing in
software methodologies and tools to improve these areas.
We have described several software processes, leading into the currently popular itera-
tive and incremental Agile process of Scrum (see Chapter 5). In the Agile processes, soft-
ware is developed in small increments by small teams. Thus, with Agile processes, there is
frequent unit testing of the completed code to ensure that what is developed is of good
quality and satisfies the customer/user needs. In Chapter 10, we introduced Test-driven
development (TDD) with
JUnit
tool. A more recent approach to improving unit testing
is the usage of formal assertions with a run-time assertion checker to decide whether the
coded software methods are working correctly. This new approach to unit testing uses a
combination of formal specification language called Java Modeling Language (JML) and
the
JUnit
testing framework (Cheon and Leavens 2004).
JML is heavily influenced by the Eiffel language and the concept of “programming by
contract” professed by Bertrand Meyer (1988). The key to this approach is using the tra-
ditional notion in program correctness proofs by specifying precondition, postcondition,
and the invariant characteristics of the software to help in unit testing. JML is a language
that allows one to specify the pre-, post-, and invariant conditions without requiring the
deep formalism in past specification languages such as Z or Larch. A tool called JMLUnit
generates
JUnit
test classes from these JML specifications. During execution, the tool
checks that if the specified preconditions for a software method hold, the specified post-
conditions for that method will also hold. Clearly, with JML and the associated tools, the
better the person who specifies these conditions, the more effective the methodology
and the more valuable the tool will be. Although JML is tailored to Java programming
development, which is fairly easy to use for Java programmers, it still requires technically
sophisticated people to develop these pre-, post-, and invariant assertions. Through
checking the assertions and ensuring that the pre- and postconditions match and that
the invariant condition holds, this relatively new approach provides a marked improve-
ment in software verification. Refer to Chalin et al. (2006) and Burdy et al. (2005) in the
Suggested Readings section for more on JML and the associated tools.
A similar approach to improving unit testing in the Agile process environment, origi-
nating directly from the test-driven development methodology, is the behavior-driven
development (BDD) approach. BDD was first introduced by Dan North in 2006. The basic
idea here is to use the language of the business domain, as opposed to technical speci-
fications in JML, and involve the users and the stakeholders of the software.
Involving
the stakeholders and users during unit testing and ensuring that the delivered software
functionality is acceptable to them is an excellent way to validate the software. Thus
BDD moves unit testing closer to validation of software functionality beyond software
verification. The natural language of the users is used to express the features and func-
tionalities through scenarios. A scenario is just a set of natural language assertions that
14.3 Software Validation and Verification Methodologies and Tools
299
91998_CH14_Tsui.indd 299 1/10/13 12:14:37 PM
describes the conditions that the software feature must satisfy. Users can easily under-
stand and validate if the unit testing satisfied their needs expressed by them in their
own normal language. The previously mentioned pre-, post-, and invariant conditions in
JML are tucked into these scenarios expressed with natural domain languages. Thus this
approach is much more inclusive and allows nontechnical stakeholders to participate in
the development of unit tests and acceptance criteria. There is a guideline to express-
ing a scenario. The standard guideline, in the Cucumber tool described by Wynne and
Hellesoy (2012), is to express a scenario with three major segments as follows:
n
Given
n
When
n
Then
A scenario is thought of in terms of what the “given” state or condition for the feature
to function is. The “when” segment of the scenario describes the stimulus, and the “then”
segment describes the result. For example, for the functionality of adding a student into
a course, one may describe the scenario as follows:
Scenario: Enrolling a student into a course.
Given: The course has not reached its student limit.
When: Enroll a student into a course.
Then: The student is added to the course’s student list.
Clearly, this scenario may be expressed and understood by both technical and non-
technical people. Using this approach, the BDD methodology, along with a tool such as
Cucumber, becomes more inclusive and allows the functional and feature validation to
be accomplished within unit testing. The Cucumber tool will assist in the development
of the unit test and the code for this functionality.
The development and generation of the actual test case itself, in the form of code,
still requires programming knowledge. The Cucumber tool is based on another popular
language platform, Ruby on Rails. Refer to Tate and Hibbs’s (2006) description of Ruby on
Rails in the Suggested Readings section.
We are seeing more and more automation and methodology improvements in soft-
ware development today. As we mechanize more of the development activities, the
chance of software project success in terms of cost, schedule, quality, and customer
acceptance should also improve.
14.4 Suggested Readings
V. Balachandran and S. Emmanuel, “Software Code Obfuscation by Hiding Control Flow
Information in Stack,” International Workshop on Information Forensics and Security
Iguacu, Brazil (November 2011).
B. Barak et al., “On the Impossibility of Obfuscating Programs,” Proceedings of the 21st
Annual International Cryptology Conference on Advances in Cryptology, Santa Barbara,
California (August 2001): 19–23.
Build Security In (BSI), https://buildsecurityin.us-cert.gov/daisy/bsi/home.html, 2009.
300 Chapter 14 Epilogue and Some Contemporary Issues
91998_CH14_Tsui.indd 300 1/10/13 12:14:37 PM
L. Burdy et al., “An Overview of JML Tools and Applications,” International Journal on Soft-
ware Tools for Technology Transfer 7 no. 3 (June 2005): 212–232.
R. A. Caralli, “Sustaining Operational Resiliency: A Process Improvement Approach to
Security Management.” Technical Note CMU/SEI-2006-TN-009 (April 2006).
P. Chalin, J. R. Kiniry, G. T. Leavens, and E. Poll, “Beyond Assertions: Advanced Specifica-
tions and Verifications with JML and ESC/Java2,” In Formal Methods for Components and
Objects (Springer Verlag, 2006).
M. T. Chan and L. F. Kwok, “Integrating Security Design into the Software Development
Process for E-commerce Systems,” Information Management Computer Security 9, no. 3
(2001): 112–122.
Y. Cheon and G. T. Leavens, “The JML and JUnit Way of Unit Testing and Its Implementa-
tion,” Technical Report #64-02, Department of Computer Science, Iowa State University
(2004).
C. S. Collberg and C. Thomborson, “Watermarking, Tamper-Proofing, and Obfuscation—
Tools for Software Protection,” IEEE Transactions on Software Engineering 28, no. 8 (August
2002): 735–746.
C. Finch, “The Benefits of the Software-as-a-Service Model,” Computerworld, http://www.
computerworld.com/5/article/107276/The_Benefits_of_a_Software_as_a_service_Mod-
el, January 2, 2006.
S. Garfinkel, “Privacy Requires Security, Not Abstinence,” MIT Technology Review 112, no. 4
(2009): 64–71.
M. Howard and D. Leblanc, Writing Secure Code, 2nd ed. (Redmond, WA: Microsoft Press,
2003).
M. Howard and S. Lipner, The Security Development Lifecycle (Redmond, WA: Microsoft
Press, 2006).
B. Meyer, Object-Oriented Software Construction (Cambridge, UK: Prentice Hall Interna-
tional, 1988).
D. North, “Introducing BDD,” http://dannorth.net/introducing-bdd/, 2006.
B. A. Tate and C. Hibbs, Ruby on Rails (Sebastopol, CA: O‘Reilly Media, 2006)
F. Tsui, S. Duggins, and O. Karam, “Software Protection with Increased Complexity and
Obfuscation,” 49th ACM SE Conference, Tuscaloosa, Alabama (March 2012).
M. Wynne and A. Hellesoy, The Cucumber Book: A Behaviour-Driven Development for
Testers and Developers (Dallas, TX: The Pragmatic Book, 2012).
O. Zimmermann et al. “Service-Oriented Architecture and Business Process Choreo graphy
in an Order Management Scenario: Rationale, Concepts, Lessons Learned.” OOPSLA 05,
San Diego, CA (October, 2005).
14.4 Suggested Readings
301
91998_CH14_Tsui.indd 301 1/10/13 12:14:37 PM
91998_CH14_Tsui.indd 302 1/10/13 12:14:37 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.