dr. keith shomper

CS 4810 – Software Engineering I 1Introduction

Dr. Keith Shomper

CS 4810

Software Engineering I


Objectives

The Course Title is: CS 4810, Software Engineering I

• Our objective – We are here to prepare students to serve God as software engineers by:– Gaining an understanding of how a major software

development project is managed and conducted– In past courses we’ve concentrated on the requirements

analysis and design in CS4810 and implementation, testing, and maintenance in CS4820.

• Approach– Major project (2 semesters)– Some lecture– Some student presentations– A lot of “figure it out as you go”


Introduction

• To a large extent, you will have a “clean slate” to work with on your development project– You will decide on the processes to use– You will decide on the document formats and how to apply

tools such as UML and Rational Development Suite– You will determine the schedule for releases

• Although I will have a schedule for progress reporting• Welcome to the “real world”

– Think of yourself as a member of a small “startup” company– You don’t have any processes in place, and need to develop

them from scratch


Introduction

• So, we are here to study Software Engineering– Sounds good, but it would help to know what it is– Hopefully you have an idea of what Software is

• Involves not only the code, but the associated documentation

• But what is Engineering?

• Accreditation Board for Engineering and Technology (the folks that accredit ENGR and will accredit us) definition:

The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind

• Does this apply to what we do?


Introduction

• Sommerville - “Software engineering is an engineering discipline which is concerned about all aspects of software production”– It is an engineering discipline

• It applies established, time-tested methodologies– It is concerned about all aspects of software production

• It involves the processes and tools for managing a software development project

• It involves the product itself• Unfortunately, there is an inherent tension between managers

and programmers– Managers live by the process

• From programmers’ perspective, the process becomes the end in itself

– Programmers focus on the product• “You don’t sell processes, you sell code”

• Which perspective is correct?


Introduction

• Hopefully we understand what Software Engineering is– But we haven’t addressed the why – why do we need

software engineering?

Computer software has become a driving force. It is the engine that drives business decision making. It serves as the basis for modern scientific investigation and engineering problem solving. It is a key factor that differentiates modern products and services. It is embedded in systems of all kinds: transportation, medical, telecommunications, military, industrial processes, entertainment, office products, … the list is almost endless. Software is virtually inescapable in a modern world. And as we move into the twenty-first century, it will become the driver for new advances in everything from elementary education to genetic engineering. Pressman

… and we find it very difficult to develop


Introduction

• Building software is hard … well, duh?

The net result is that building and maintaining software is hard and getting harder; building quality software in a repeatable and predictable fashion is harder still - Grady Booch

• Some estimates say that only about 30% of software development projects are successful

• Even those that are successful leave us asking questions:– Why does it take so long to get software finished?– Why are development costs so high?– Why can’t we find all the errors before we give the software

to the customer? (or why do we look so much like Microsoft)– Why do we have trouble gaining insight into how (or

whether) the project is progressing?


Introduction

• Bottomline: the days where software is developed by a guru who stays up all night eating pepperoni pizza are gone!

• We need to learn to follow accepted “best practices” in a disciplined manner when we develop software– An engineer building a bridge doesn’t just “make it up as he

goes”• There are established, accepted procedures• Developed over many years of experience

– Unfortunately, software engineering is a very “young” discipline

• We are still developing our “best practices”• Those that we teach today will probably be considered

“feeble attempts” in just a few years


Introduction

• The rapidly increasing complexity of software is one of the prime reasons we focus so much on software engineering– How many of you built a fort or a treehouse or a doghouse

as a kid?– How does this differ from building a house, or SSC?

• Hopefully we can see the need for more rigorous methodologies for developing software– That doesn’t necessarily make it fun– But we get much more utility out of a building like SSC than

we would from a doghouse (unless of course you are a dog)


Introduction

• Despite Claims of a Software Crisis—Why has it not materialized?– More “Stuff” to Build Upon– Better Communications– Better Development Tools– Easier Interfaces—More Standardized– Object-Oriented Paradigm– Better Languages and Libraries– Better Practices

• This is SE. It improves our ability to make better s/w, but not dramatically so.


Introduction

• With all this new emphasis on software engineering, the terminology is getting confusing - what am I?– Computer scientist?– Programmer?– Software engineer?

• Computer scientists This is the segment of your education that remains fixed over a long period of time. Algorithms, Operating Systems, Boolean Math. These are academics.

• Programmers stay up all night and eat pepperoni pizza• Industry isn’t all that interested in them anymore

• Software engineers apply established practices to develop quality software


Introduction

• Other terminology which might be confusing– Computer Engineer – mostly focuses on hardware

• 70-30 hardware, versus 90-10 software • Often embedded systems which have combination of

hardware/software– Systems Engineer – also combines hardware and software

knowledge• Rather than doing detailed design of either, focuses on

how to integrate the two• Involved in specifying the system, defining its overall

architecture, and then integrating the different parts to create a finished system

– Usually using COTS• If Cedarville were to go “wireless,” a systems engineer

might specify what hardware and software to buy


Introduction

• People are just now recognizing the need for Software Engineers rather than Programmers– In 1998, Texas became the first place in the U.S. where you

can register as a professional Software Engineer– ACM and IEEE Computer Society are looking now at norms

for establishing Software Engineering as a recognized engineering profession

• We need to work to change the mindset from the idea of a Programmer to that of a Software Engineer– Some schools are offering degrees in Software Engineering

rather than Computer Science

Well, if we’re going to be engineers, guess it must be time for us to go buy our pocket protectors


Introduction

• Software development is not well understood by most• Some software myths:

– Software can be manufactured• “I need something that looks like this .. go build it”• Reality: it is more like building a bridge – every situation

is unique and requires application of engineering judgment

– If we get behind schedule, we can add programmers to catch up

• Reality: adding people to a late software project makes it later

– We provided our programmers with a great development environment: they have the best computer hardware

• Reality: need to have (and use) software tools


Introduction

• Software myths (cont)– Software doesn’t wear out

• Hardware follows the “bathtub” curve• Software should just get better!

Failure Curves

Time

Failu

re R

ate

Hardware

SoftwareInfant mortality

Wearing out


Introduction

• Software myths (cont)– Software doesn’t wear out (cont)

• Reality: software doesn’t wear out like hardware, but it does deteriorate

– As it gets “patched” over and over, the reliability of the software ends up decreasing,

– Likewise, it gets more and more difficult to maintain– Objects and Components have revolutionized the reuse of

software• Reality: most software still built from scratch

– NIH (not invented here) syndrome


Introduction

• Software myths (cont)– A general statement of objectives is sufficient to start writing

programs; we can fill in details later• Reality: poor up-front definition of the problem is the

major cause of failed software efforts– Project requirements continually change, but software is

flexible and can easily accommodate change• Reality: Change early in the development process are

relatively easy to incorporate. Change later in the process can have an order of magnitude more impact on cost and schedule

– Once we get the code working, the job is done• Reality: Industry data shows that 60-80% of software

development effort occurs after delivery to the customer– Bug fixes, enhancements


Introduction

• Software myths (cont)– The only deliverable from a successful project is a working

program• Reality: Documentation is essential

– User will need documentation– Just as importantly, program cannot be maintained

without proper documentation– Software engineering will require creation of voluminous and

unnecessary documentation, and will slow us down• Reality: voluminous – yes; unnecessary – no

– Doing it right the first time speeds the overall process– Having it documented for maintainability is

indispensable to be able to make time-effective changes


Introduction

• Summary: Software engineering was born out of the ashes of failed programs– It certainly goes against the grain of us “hackers” – But it has proven to be effective in producing successful

projects– It is still in its infancy

• Think about how many centuries we have been building houses/bridges and developing the “best practices” for this type of engineering

• People have been thinking seriously about Software Engineering for only 10-15 years now

• It is certain to continue to evolve and grow– Warning: don’t accept today’s fads as “gospel” and don’t

think one magic technique will work for all projects• Process for large projects should be different than for

small projects

dr. keith shomper

Documents