Software Engineering: An Introduction - PowerPoint PPT Presentation

Loading...

PPT – Software Engineering: An Introduction PowerPoint presentation | free to view - id: 436a24-ZjA5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Engineering: An Introduction

Description:

Software Engineering: An Introduction Object-Oriented Software Engineering CS350 Responsibilities for Engineering and Geo-science Software Developing software is a ... – PowerPoint PPT presentation

Number of Views:96
Avg rating:3.0/5.0
Slides: 37
Provided by: joe49
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Engineering: An Introduction


1
Software Engineering An Introduction
  • Object-Oriented Software Engineering CS350

2
Software Engineering
  • The application of a systematic, disciplined,
    quantifiable approach to the design, development,
    operation, and maintenance of software, and the
    study of these approaches

3
Software Engineering
  • Emergence as a profession
  • Early 1980s Software engineering had emerged as
    a bonafide profession
  • Role of women
  • 1940s, 1950s, and 1960s Grace Hopper, Jamie
    Fenton and many other unsung women filled many
    programming jobs during the first several decades
    of software engineering
  • Today fewer women work in software engineering
    than in other profesions
  • Why?

4
Software Engineering
  • Processes
  • Have become a big part of SE
  • Hailed for their potential to improve software
    and sharply criticized for their potential to
    constrict programmers
  • Cost of hardware
  • Computers are now more numerous and more powerful
  • Market can support large projects to create
    commercial off the shelf software
  • Cheap machines allow each programmer to have a
    terminal capable of fairly rapid compilation
  • Can use techniques such as garbage collection
  • Organizations use commercial off the shelf
    software instead of employing programmers for
    large custom software projects

5
The Pioneering Era
  • New computers were coming out almost every year
    or two
  • Software people had to rewrite all their programs
    to run on these new machines
  • Machine room Jobs were run by
  • Signing up for machine time or by operational
    staff
  • Using punched cards for and waiting for results
    to come back

6
The Pioneering Era
  • The idea of management by schedule was
    non-existent
  • Making predictions was almost impossible
  • Computer hardware was application-specific
  • Scientific and business tasks needed different
    machines
  • The notion of reuse flourished

7
1945 to 1965 The Origins
  • The term software engineering first appeared in
    the late 1950s and early 1960s
  • Programmers have always known about civil,
    electrical, and computer engineering and debated
    what engineering might mean for software

8
1965 to 1985 The Software Crisis
  • Spurred by the so-called software crisis of the
    1960s, 1970s, and 1980s
  • Many software projects ran over budget and
    schedule
  • Some projects caused property damage
  • A few projects caused loss of life

9
1965 to 1985 Cost and Budget Overruns
  • Example OS/360 operating system
  • Decade-long project from the 1960s eventually
    produced one of the most complex software systems
    at the time
  • One of the first large (1000 programmers)
    software projects
  • Fred Brooks (The Mythical Man Month) claims he
    made a mistake of not developing a coherent
    architecture before starting development

10
1965 to 1985 Property Damage
  • Software defects can cause property damage
  • Poor software security allows hackers to steal
    identities, costing time, money, and reputations

11
1965 to 1985 Life and Death
  • Software defects can kill
  • Example Therac 25 incident

12
1965 to 1985
  • Main source of SE difficulties is a lack of
    specialization
  • There is a need for a "normal practice" of
    software engineering, a prerequisite if software
    engineering is to become an engineering science
  • (Michael Jackson, "Engineering and Software
    Engineering" in The Future of Software
    Engineering, Springer Verlag 2010 Michael
    Jackson, Problem Frames Analyzing and
    Structuring Software Development Problems
    Addison-Wesley, 2001)

13
1985 to 1989 No Silver Bullet
  • For decades, solving the software crisis meant
    producing software tools
  • But the cost of owning/maintaining software in
    the 1980s was double developing the software
  • By 1995, half of surveyed development projects
    were operational, but not successful

14
1985 to 1989 Software projects
  • Every new technology and practice was trumpeted
    as a silver
  • Tools, discipline, formal methods, process, and
    professionalism were touted as silver bullets

15
1985 to 1989 Tools
  • Structured programming
  • Object-oriented programming
  • CASE tools
  • Ada
  • Documentation
  • Standards

16
1985 to 1989 Discipline
  • Was the software crisis due to the lack of
    discipline of programmers?
  • Your thoughts?

17
1985 to 1989 Formal methods
  • If formal engineering methodologies were applied
    to software development
  • Then production of software could bee as
    predictable as other branches of engineering
  • Think programs correctness

18
1985 to 1989 Process
  • Capability Maturity Model
  • Initial (chaotic, ad hoc, individual heroics) -
    the starting point for use of a new or
    undocumented repeat process.
  • Repeatable - the process is at least documented
    sufficiently such that repeating the same steps
    may be attempted.
  • Defined - the process is defined/confirmed as a
    standard business process, and decomposed to
    levels 0, 1 and 2 (the latter being Work
    Instructions).
  • Managed - the process is quantitatively managed
    in accordance with agreed-upon metrics.
  • Optimizing - process management includes
    deliberate process optimization/improvement.

19
1985 to 1989 Professionalism
  • Code of ethics
  • Licenses
  • Professionalism.

20
1985 to 1989
  • No Silver Bullet article (Fred Brooks, 1986)
  • No individual technology or practice would ever
    make a 10-fold improvement in productivity within
    10 years
  • Eventually, almost everyone accepted that no
    silver bullet would ever be found
  • Does no silver bullet mean that software
    engineering failed?
  • Brooks says, We will surely make substantial
    progress over the next 40 years an order of
    magnitude over 40 years is hardly magical ....

21
1985 to 1989
  • It could be said that there are, in fact, a range
    of silver bullets today, including
  • Lightweight methodologies
  • Spreadsheet calculators
  • Customized browsers
  • In-site search engines
  • Database report generators
  • Integrated design-test coding-editors with
    memory/differences/undo
  • Specialty shops

22
1990 to 1999 Prominence of the Internet
  • The rise of the Internet led to a demand for
  • Illustrations
  • Maps
  • Photographs
  • Simple animation
  • Issues
  • Widespread network connections led to the growth
    prevention of international computer viruses
  • Vast proliferation of spam e-mail became a major
    design issue in e-mail systems
  • Keyword-search systems evolved into web-based
    search engines
  • Human natural-language translation systems were
    needed

23
2000 to Present Lightweight Methodologies
  • Expanding demand for software in many smaller
    organizations meant the need for inexpensive
    software
  • Rapid-prototyping evolved to entire lightweight
    methodologies
  • Extreme Programming (XP)
  • Very large software systems still used
    heavily-documented methodologies
  • Smaller systems had a simpler, faster alternative
    approach

24
Current Trends
  • Aspects Help software engineers deal with
    quality attributes by providing tools to add or
    remove boilerplate code from many areas in the
    source code. Aspects describe how all objects or
    functions should behave in particular
    circumstances. For example, aspects can add
    debugging, logging, or locking control into all
    objects of particular types. Researchers are
    currently working to understand how to use
    aspects to design general-purpose code. Related
    concepts include generative programming and
    templates.

25
Current Trends
  • Agile Agile software development guides software
    development projects that evolve rapidly with
    changing expectations and competitive markets.
    Proponents of this method believe that heavy,
    document-driven processes (like TickIT, CMM and
    ISO 9000) are fading in importance. Some people
    believe that companies and agencies export many
    of the jobs that can be guided by heavy-weight
    processes. Related concepts include extreme
    programming, scrum, and lean software
    development.

26
Current Trends
  • Experimental experimental software engineering
    is a branch of software engineering interested in
    devising experiments on software, in collecting
    data from the experiments, and in devising laws
    and theories from this data. Proponents of this
    method advocate that the nature of software is
    such that we can advance the knowledge on
    software through experiments only.

27
Current Trends
  • Model-driven model driven design develops
    textual and graphical models as primary design
    artifacts. Development tools are available that
    use model transformation and code generation to
    generate well-organized code fragments that serve
    as a basis for producing complete applications.

28
Current Trends
  • Software product lines software product lines
    is a systematic way to produce families of
    software systems, instead of creating a
    succession of completely individual products.
    This method emphasizes extensive, systematic,
    formal code reuse, to try to industrialize the
    software development process.

29
Software engineering today
  • The profession is trying to define its boundary
    and content. The Software Engineering Body of
    Knowledge SWEBOK has been tabled as an ISO
    standard during 2006 (ISO/IEC TR 19759).
  • In 2006, Money Magazine and Salary.com rated
    software engineering as the best job in America
    in terms of growth, pay, stress levels,
    flexibility in hours and working environment,
    creativity, and how easy it is to enter and
    advance in the field.

30
Ethical considerations
  • Software engineering ethics is a large field. In
    some ways it began as an unrealistic attempt to
    define bugs as unethical. More recently it has
    been defined as the application of both computer
    science and engineering philosophy, principles,
    and practices to the design and development of
    software systems. Due to this engineering focus
    and the increased use of software in mission
    critical and human critical systems, where
    failure can result in large losses of capital but
    more importantly lives such as the Therac-25
    system, many ethical codes have been developed by
    a number of societies, associations and
    organizations. These entities, such as the ACM,
    IEEE, APEGBC and Institute for Certification of
    Computing Professionals (ICCP) have formal codes
    of ethics. Adherence to the code of ethics is
    required as a condition of membership or
    certification. According to the ICCP, violation
    of the code can result in revocation of the
    certificate. Also, all engineering societies
    require conformance to their ethical codes
    violation of the code results in the revocation
    of the license to practice engineering in the
    society's jurisdiction.
  • These codes of ethics usually have much in
    common. They typically relate the need to act
    consistently with the client's interest,
    employer's interest, and most importantly the
    public's interest. They also outline the need to
    act with professionalism and to promote an
    ethical approach to the profession.
  • A Software Engineering Code of Ethics has been
    approved by the ACM and the IEEE-CS as the
    standard for teaching and practicing software
    engineering.

31
Examples of Codes of Conduct
  • The following are examples of Codes of conduct
    for Professional Engineers. These 2 have been
    chosen because both jurisdictions have a
    designation for Professional Software Engineers.
  • Association of Professional Engineers and
    Geo-scientists of British Columbia (APEGBC) All
    members in the association's code of Ethics must
    ensure that government, the public can rely on
    BC's professional engineers and Geo-scientists to
    act at all times with fairness, courtesy and good
    faith to their employers, employee and customers,
    and to uphold the truth, honesty and
    trustworthiness, and to safe guard human life and
    the environment. This is just one of the many
    ways in which BCs Professional Engineers and
    Professional Geo-scientists maintain their
    competitive edge in todays global marketplace.
  • Association of Professional Engineers,
    Geo-scientists and Geophysicists of
    Alberta(APEGGA) Different with British Columbia,
    the Alberta Government granted self governance to
    engineers, Geo-scientists and geophysicists. All
    members in the APEGGA have to accept legal and
    ethical responsibility for the work and to hold
    the interest of the public and society. The
    APEGGA is a standards guideline of professional
    practice to uphold the protection of public
    interest for engineering, Geo-scientists and
    geophysics in Alberta.

32
Opinions on ethics
  • Bill Joy argued that "better software" can only
    enable its privileged end users, make reality
    more power-pointy as opposed to more humane, and
    ultimately run away with itself so that "the
    future doesn't need us." He openly questioned the
    goals of software engineering in this respect,
    asking why it isn't trying to be more ethical
    rather than more efficient. In his book Code and
    Other Laws of Cyberspace, Lawrence Lessig argues
    that computer code can regulate conduct in much
    the same way as the legal code. Lessig and Joy
    urge people to think about the consequences of
    the software being developed, not only in a
    functional way, but also in how it affects the
    public and society as a whole.
  • Overall, due to the youth of software
    engineering, many of the ethical codes and values
    have been borrowed from other fields, such as
    mechanical and civil engineering. However, there
    are many ethical questions that even these, much
    older, disciplines have not encountered.
    Questions about the ethical impact of internet
    applications, which have a global reach, have
    never been encountered until recently and other
    ethical questions are still to be encountered.
    This means the ethical codes for software
    engineering are a work in progress, that will
    change and update as more questions arise.

33
Professional responsibilities in developing
software
  • Who's Responsible?
  • The developers work with clients and users to
    define system requirements. Once the system is
    built if any accidents occur, such as economical
    harm or other, who is responsible?
  • If an independent QA team does integration
    testing and does not discover a critical fault in
    the system, who is ethically responsible for
    damage caused by that fault?

34
Responsibilities for Engineering and Geo-science
Software
  • Developing software is a highly risky
    proposition. The software development process is
    a complex undertaking consisting of specifying,
    designing, implementing, and testing. Any small
    mistake or fault will cause unlimited damage to
    society. Professional Members contribute to the
    success of software development projects.
    However, Association of Professional Engineering
    and Geo-science is primarily concerned with their
    responsibility for minimizing the risk of failure
    and protecting the public interest

35
Systems Engineering
  • Systems engineers deal primarily with the overall
    system requirements and design, including
    hardware and human issues. They are often
    concerned with partitioning functionality to
    hardware, software or human operators. Therefore,
    the output of the systems engineering process
    serves as an input to the software engineering
    process.

36
Engineering process
  • The definition, implementation, assessment,
    measurement, management, change, and improvement
    of the software life cycle process itself.
About PowerShow.com