Escolar Documentos
Profissional Documentos
Cultura Documentos
Software Engineering
All right reserved, 2002-2013. The Software Engineering module, in all its parts:
syllabus, guidelines, lectures, discussion questions, technical notes, images and any
additional material is copyrighted by Laureate Online Education
Module: SE
Seminar 1
the microchip, the cost of hardware development considerably decreased, but the cost
of software continued to rise. The industry refocused its efforts on the development of
software. The rapid growth of computer use was fueled with the introduction of the
microcomputer thirty-five years ago. Software became the key factor in growth of the
microcomputer.
A variety of reasons contributed to dramatic rise in the cost of software. In the 1970s,
new software development companies proliferated to write software that could be
modified for a variety tasks for a variety of clients. Organizations jumped at the chance
to buy software that was pre-packaged. This concept was never realized for
enterprise applications. In fact, the opposite became true. Organizations soon
recognized that, since the software was written for many customers, programmers were
needed to build enterprise interfaces and modify standard installs. Millions of lines of
code were developed or modified by in-house programmer teams. Most of this
software was written as a quick, temporary fix to a specific problem. Very little analysis
was done, and little or no documentation was written. The maintenance of these
applications became a nightmare, and since software does not wear out, quick fixes
often stayed in place for years. These have become the legacy systems which many
enterprises continue to maintain at a very high cost.
There were no defined standards for software development in the early systems.
Documentation was poor. The fact that Computer Science as a discipline was just
emerging in colleges and universities further compounded software development
problems. Most software programs were written by self-taught programmers. As a
group, internal technical staff members responsible for developing and maintaining inhouse code were not trained software developers. Thus, they often did not have a
broad understanding of the need for standardized processes to improve maintainability.
Software was written specifically for a specific hardware platform with no thought to
portability. When new equipment and/or operating systems were installed, major rewrites of the code were necessary. Maintenance of the programs continued to eat into
corporate revenues. More programmers were hired to maintain aging software. The
cost of software soared. The industry began to seek solutions for these problems.
By the late 70s, the phrase Software Crisis was coined. The primary characteristics of
the problem included
1. The inability to complete software projects on time. Some projects were reaching
years past their scheduled due date.
2. Low cost estimates for software projects. Some projects were costing 5 to10 times
the original estimate.
3. Questionable software quality with continuing need for major software patches. It
was not unusual to have a version 4.0, 4.1, 4.3, 4.5 on a single product where each
version fixed a major problem in the software.
2
4. Weak project managers who had sound management skills but little understanding of
managing technical staff working on software projects
Software was and continues to be a logical system as opposed to a physical system
(such as a building or a bridge). Since each piece of software is developed with mind
power, the development of software was and continues to be very labor intensive.
Compounding this was the inability to develop reusable code so every project was
reinventing the wheel.
As the microchip permeated the computer industry, the development of distributed
systems and personal computers exploded. This explosion of computing for the masses
was the catalyst for the growth of software companies. The increase of the userfriendly software in the 1980s sold application packages such as word processors,
spreadsheets, and databases as commodity products. The world was not prepared for
the human resource needs necessary to sustain the demand of software development.
A Solution
By the late 70s, the computer industry was desperate to put procedures in place to
combat some of these problems. They pulled concepts from both management and
engineering to develop standards for software development. Fritz Bauer (at the First
NATO Conference on Software Engineering, 1969) provided an early definition of this
process that evolved as Software Engineering The establishment and use of sound
engineering principles in order to obtain economically software that is reliable and works
efficiently on real machines (Randell, 1996) . The assumption was that we could use
the same techniques used by engineers building physical structures to build (develop)
software. Software engineering provides standard structures for the development of
software. These structures include procedures which drive the development of software
and the techniques by which we follow to improve cost and time estimates. The key
tools used to drive the software engineering process have become CASE tools.
Systems Engineering
Systems engineering is the process of designing socio-technical (human, social, and
environmental) systems that produce a product. The primary focus is to understand the
system by following a standard processes: functional and requirements analysis which
includes designing, implementing, and testing to verify the product meets the
requirements. Such activities as the study of human factors, reliability, feasibility, and
safety are part of this overall effort.
The process of systems engineering is explained clearly in the text -- the final goal of
the formal process is to design a system that addresses as many variables as possible
to improve our ability to develop a successful system.
3
requirements early in the process. Once the requirements are defined and the
customer has signed off on them, the process moves to the design phase. The design
phase translates the requirements into an architectural representation of the total
system which is used to map the coding process. The implementation phase converts
the design model into a working software model. The testing phase focuses on testing
both logical and functional tasks to discover errors, and finally the operation and
maintenance phase works to maintain a running product and further enhancements.
There are difficulties in the waterfall model (Lewallen, 2005). One major drawback is
the need to define a complete set of software requirements early in the development
cycle. It does not allow for on-going changes in requirements. This is especially
problematic with the complexity of software development of large projects where the
environment and tools are constantly evolving and changing. After looking at the
emerging trends, we can see where the waterfall approach would not be effective for
most of the rapidly developing complex systems. The nature of current software
development efforts requires software to be developed in phases where each phase
then determines the requirements of the next phase.
The evolutionary development process addresses some of these issues and allows
for an initial implementation of user requirements and new features added by customers
as they are defined (Figure 2.2. in Sommerville). The advantage here is the ability to
design specifications incrementally. The newer approaches to Project Management use
this approach. The Team Software ProcessSM (TSPSM) developed by the Software
Engineering Institute (Humphrey, 2002) is based on the cyclic development of software.
Agile Programming is a form of an evolutionary development process.
The disadvantage of phase development lies in the possibility of a poorly structured
system if not managed properly. It is also often difficult to determine the scope of the
project because customers could theoretically add requirements and features
indefinitely. Thus, it is best used for small systems, although it is evolving and has been
used for larger projects. The splintered development sometimes produces serious
problems for large projects. It appears, however, to be successful in bringing a project
to completion (Snbl, et al, 2001). The statistics collected on the Agile approach are
encouraging. A survey completed by Ambysoft Corporation found that Agile success
rates (72%) were better that the traditional approach (63%) (Ambler, 2007)
Component based software engineering (CBSE) is based on the concept of Code
Reuse using existing components of source code to develop new software systems.
(Qureshi and Hussain, 2008) These components include not only programming code,
but also documentation, architectural design, and data. The underlying concept is that
code reliability can be increased and the cost reduced by using fully validated code and
8
tools. Somerville addresses the basic foundation of COTS and CBSE in Chapter 16.
We will study this in detail in Seminar 6.
Process Activities
With any of these approaches, it is necessary to determine the problem space, define a
solution, implement, and test these implementations. Thus, developmental approaches
are different; each has processes in common that follow this sequence.
Software Specification
Software specification defines what services are required from the system. This
technique is called requirements engineering. Requirements engineering includes four main
phases:
Feasibility study We can assume that most projects are feasible given unlimited resources
and unlimited time. Thus, we need to determine whether the project is feasible given what we
have to work with.
Requirements Elicitation and Analysis Once we determine the project can be
accomplished with the available resources, the system requirements are identified. One of the
best methods is the use of a software prototype. We now have rapid prototyping tools allowing
us to simulate a working system without completed code requirements.
Requirements Specifications We define the project specifications using the system
requirements that are defined in the requirements analysis.
Requirements Validation We perform a validation check to guarantee that that our system in
consistent and complete.
Interface Design: defines and models the interfaces between the components. Today,
we usually equate interface design to the user interface, but before the UI, we must
define how each of the software components fit together.
Component Design (discussed in Seminar 6): defines the pieces of the final solution.
No software system is developed as one large system. Instead, we design each of the
pieces (components) which we fit together into a final solution. A component may not
yet exist or we may use reusable components. The component design identifies these.
Database Design: defines the data structures and how data is represented in the
system.
Prototyping
The sooner we can provide a visual look and feel of the proposed design, the better it
is for the customer and for the designer. The problem has been that, until recently, we
had no way to create an electronic mock-up of the design without considerable effort,
and once that effort was completed, designers were reluctant to throw away their
work. Now, we have very good, inexpensive software methods to develop software
prototypes that can be easily modified or thrown away. As we develop the prototype, we
dont concern ourselves with all the system constraints.
"A software rapid prototype is a dynamic visual model that provides a communication
tool for customer & developer that is more effective for displaying functionality than
narrative prose or static visual models "(Novac, 2007). Using prototypes provides a
method of mitigating the risk of change. Since we are prototyping pieces, it is not
necessary to represent the complete system. Thus, system prototyping provides a way
to cope with change since customer ideas can be implemented to check on the
requirements. The value of rapid prototyping is the ability to construct it quickly.
There are many prototyping tools. These tools range from simple word-processing tools
to sophisticated IDE environments. A developer may use several tools for one
implementation. (Bhagwat, 2003; Rees, 1994)
Prototyping Summary
References
Ambler, S.(2007) IT Project Success Rates Survey: August 2007. Ambysoft.
http://www.ambysoft.com/surveys/success2007.html
10
11
Snbl, A., Weber H. , Padberg, J. (2001) Evolutionary Development Of Business Process Centered
Architectures Using Component Technologies. Journal of Integrated Design & Process Science Vol 5,
Issue 3 (August, 2001)
Additional Reading
Rubinstein, D (2007). Standish Group Report: Theres Less Development Chaos Today. SDTimes
(March 1,2007). http://www.sdtimes.com/content/article.aspx?ArticleID=30247
Standish Group 2009). New CHAOS numbers show startling results. April 23, 2009.
http://www1.standishgroup.com/newsroom/chaos_2009.php
The following books provide more information on the topic of software engineering:
Pressman, R. (2005), Software Engineering, A Practitioners Approach (6th Edition), McGraw Hill. Good
textbook, but a little on the technical side.
Brooks, F. (1995) The Mythical Man-Month, Essays on Software Engineering, Addison Wesley. Fred
Brooks was the original Project Manager for the IBM 360 hardware as well as for its MVS operating
system, and although some of the book is dated, his observations are still widely accepted as the
foundation of software engineering. ISBN-10: 0201835959
Reading Assignments
The assigned readings for this seminar are Chapter 1 and Chapter 2
The assignments for Week 1 are in the Assignment file.
12