Post on 11-May-2015
transcript
Basic Concepts Basic Concepts of of Software Software EngineeringEngineering
Basic Concepts Basic Concepts of of Software Software EngineeringEngineering
Chapter I
Computer Science & Software Computer Science & Software EngineeringEngineering
Computer Science is concerned with Theory and Fundamentals.
Software Engineering is concerned with the practicalities of Developing and Delivering
Useful software.
Software ProcessSoftware Process
Software process - set of activities Goal – Development or evolution of software
Generic activities in all software processes are: Specification.
What the system should do and its development constraints.
Development. Production of the software system.
Validation. Checking that the software is what the customer wants.
Evolution. Changing the software in response to changing demands.
Software Process ModelSoftware Process Model
Software process model Representation of S/W process in a specific perspective
Examples of process perspectives are Workflow perspective - sequence of activities Data-flow perspective - information flow Role/action perspective - who does what
Generic process models Waterfall Evolutionary development Formal transformation Integration from reusable components
Costs of Software Costs of Software EngineeringEngineering
Roughly 60% of costs are development costs, 40% are testing costs.
For custom software, evolution costs often exceed development costs.
Costs vary depending on The type of system being developed and The requirements of system attributes such as
Performance and system reliability
Distribution of costs depends on The development model that is used
Software Engineering MethodsSoftware Engineering Methods
Structured approaches to software development includes:
Model descriptions Descriptions of graphical models.
Rules Constraints applied to system models.
Recommendations Advice on good design practice.
Process guidance What activities to follow.
CASE (Computer-Aided SE)CASE (Computer-Aided SE)
CASE systems Intended to provide automated support for software process activities.
Upper-CASE Tools to support the early process activities
Requirements and Design
Lower-CASE Tools to support later activities such as
Programming Debugging and Testing
Attributes of good softwareAttributes of good software
Software should deliver Required functionality and performance to the user and Should be maintainable, dependable and usable
Maintainability Software must evolve to meet changing needs
Dependability Software must be trustworthy
Efficiency Software should not make wasteful use of system resources
Usability Software must be usable by the users for which it was designed
Professional and ethical Professional and ethical responsibilityresponsibility Software engineering involves wider responsibilities than simply the
application of technical skills
Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals
Ethical behaviour is more than simply upholding the law.
Issues of professional Issues of professional responsibilityresponsibility Confidentiality
Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.
Competence Engineers should not misrepresent their level of competence.
They should not knowingly accept work which is outside their competence.
Issues of professional Issues of professional responsibilityresponsibility Intellectual property rights
Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc.
They should be careful to ensure that the intellectual property of employers and clients is protected.
Computer misuse Software engineers should not use their technical skills to misuse
other people’s computers. Computer misuse ranges from relatively trivial (game playing on
an employer’s machine) to extremely serious (dissemination of viruses).
ACM/IEEE Code of EthicsACM/IEEE Code of Ethics
The professional societies in the US have cooperated to produce a code of ethical practice.
Members of these organisations sign up to the code of practice when they join.
The Code contains eight Principles related to the behaviours of professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.
ACM - Association for Computing MachineryIEEE – Institute of Electrical and Electronics Engineers
Code of ethics - preambleCode of ethics - preamble
Preamble Software engineers shall commit themselves to making the
analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:
Code of ethics - principlesCode of ethics - principles
Public Interest
Software engineers shall act consistently with the public interest.
Client and Employer
Software engineers shall act in the best interests of their client and employer consistent with the public interest.
Product
Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
Code of ethics - principlesCode of ethics - principles
Professional Judgement Software engineers shall maintain integrity and independence
in their professional judgment.
Management
Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
Profession Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
Code of ethics - principlesCode of ethics - principles
Colleagues
Software engineers shall be fair to and supportive of their colleagues.
Self Software engineers shall participate in lifelong learning regarding
the practice of their profession and shall promote an ethical approach to the practice of the profession.
Ethical dilemmasEthical dilemmas
Disagreement in principle with the policies of senior management
Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system
Participation in the development of military weapons systems or nuclear systems.
Points to remember Points to remember
Software engineering is an engineering discipline which is concerned with all aspects of software production.
Software products consist of developed programs and associated documentation.
Essential product attributes are maintainability, dependability, efficiency and usability.
The software process consists of activities which are involved in developing software products. Basic activities are software specification, development, validation and evolution.
Points to rememberPoints to remember
Methods are organized ways of producing software. They include Suggestions for the process to be followed The notations to be used Rules governing the system descriptions.
CASE tools are software systems Designed to support routine activities in the software process.
Software engineers have responsibilities to the engineering profession and society.
Professional societies publish codes of conduct which set out the standards of behaviour expected of their members.
End End
Some Software Characteristics Software is engineered or developed, not manufactured in the
traditional sense.
Software does not wear out in the same sense as hardware.
Some Software Characteristics In theory, software does not wear out at all.
But, Hardware upgrades.
Software upgrades.
Some Software Characteristics Thus, reality is more like this.
Most serious corporations control and constrain changes
Most software is custom built, and customer never really knows what she/he wants.
Some General Approaches
Develop and use good engineering practices for building software.
Make heavy use of reusable software components.
Use modern languages that support good software development practices, e.g., Ada95, Java.
Use 4th generation languages.
But, almost everything is a two-edged sword.
Consider long term tool maintenance. Right now, this is a major problem for NASA.
Types of Software Applications Systems Software
Real-Time Software Business Software Engineering Software Embedded Software Artificial Intelligence Software Personal Computer Software
Software Myths
Myth: It’s in the software. So, we can easily change it.
Reality: Requirements changes are a major cause of software degradation.
Myth: We can solve schedule problems by adding more programmers.
Reality: Maybe. It increases coordination efforts and may slow things down.
Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code.
Reality: Incomplete up-front definition is the major cause of software project failures.
Software Myths
Myth: Writing code is the major part of creating a software product.
Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery.
Percent Maintenance Historgram
0%
5%
10%
15%
20%
25%
30%
35%
(0,15] (15,30] (30,45] (45,60] (60,75]
Software Myths Myth: I can’t tell you how well we are doing until I get parts of it running.
Reality: Formal reviews of various types both can give good information and are critical to success in large projects.
Myth: The only deliverable that matters is working code. Reality: Documentation, test history, and program configuration
are critical parts of the delivery.
Myth: I am a (super) programmer. Let me program it, and I will get it done.
Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.
25%
31%
13%
8%
6%
0%
5%
10%
15%
20%
25%
30%
35%
<=2 (2.4] (4,6] (6,8] (8,10] >10
Estimate in weeks
SLOCs per Year Histogram
0%
5%
10%
15%
20%
25%
30%
35%
40%
(0,5k] (5k,10k] (10k,20k] (20k,50k] >50k
Series1
The Classical Life Cycle
Life-cycle model The steps (phases) to follow when building software A theoretical description of what should be done
Life cycle The actual steps performed on a specific product
Classical model (1970)
1. Requirements phase2. Analysis (Specification) Phase3. Design Phase4. Implementation Phase5. Post-delivery Maintenance6. Retirement
The Classical Life Cycle Requirements phase
Explore the concept Elicit the client’s requirements
Analysis (Specification Phase) Analyze the client’s requirements Draw up the specification document Draw up the software project management plan “What the product is supposed to do”
Design Phase Architectural design, followed by Detailed design “How the product does it”
The Classical Life Cycle Implementation phase
Coding Unit testing Integration Acceptance testing
Post-delivery maintenance Corrective maintenance Perfective maintenance Adaptive maintenance
Retirement
WHICH PHASE IS THE MOST EXPENSIVE
1.3.2 The Importance of Postdelivery Maintenance Bad software is discarded
Good software is maintained, for 10, 20 years or more
Software is a model of reality, which is constantly changing
Time (= Cost) of Postdelivery Maintenance
Development – 25%
Post-Delivery Maintenance – 75%
Total Product Costs
Breakout ofDevelopment Costs
Integration – 29%
Implementation/Coding – 34%
Design – 19%
Requirements &Analysis – 18%
Consequence of Relative Costs of Phases
Suppose Coding method CMnew is 10% faster than currently used method CMold. Should it be used?
Common sense answer “Of Course”
BUT: What is the cost of training and other overhead? Reducing the coding cost by 10% yields at most a 0.85% reduction in
total costs Consider the expenses and disruption incurred Reducing postdelivery maintenance cost by 10% yields a 7.5%
reduction in overall costs
Requirements, Analysis, and Design Aspects (contd)
The earlier we detect and correct a fault, the less it costs us.
The cost of detecting and correcting a fault at each phase
Requirements, Analysis, and Design Aspects (contd)
The previous figure redrawn on a linear scale
Figure 1.6
Requirements, Analysis, and Design Aspects (contd)
To correct a fault early in the life cycle Usually just a document needs to be changed
To correct a fault late in the life cycle Change the code and the documentation Test the change itself Perform regression testing Reinstall the product on the client’s computer(s)
Between 60 and 70 percent of all faults in large-scale products are requirements, analysis, and design faults
Example: Jet Propulsion Laboratory inspections 1.9 faults per page of specifications 0.9 per page of design 0.3 per page of code
CONCLUSION: It’s vital to improve our techniques to find faults as early as possible.
The Author’s Rant
Schach claims that, with OO development, there are no distinct Planning, testing, and documenting phases.
He says these are continuous operations that don’t have distinct beginnings and endings, but instead are iterative.
His claim is that this is better than the Classical Model.
The Author’s Rant
The structured paradigm was successful initially It started to fail with larger products (> 50,000 LOC)
Postdelivery maintenance problems (today, 70 to 80 percent of total effort)
Reason: Structured methods are Action oriented (e.g., finite state machines, data flow diagrams); or Data oriented (e.g., entity-relationship diagrams, Jackson’s method); But not both
Structured versus Object-Oriented Paradigm
Information hiding Need-to-know design Impact on maintenance,
development
Account BalanceDeposit
Withdrawal
Determine Balance
Account Balance
Message
With-drawal
Determine Balance
Account Balance
Deposit
Message
Message
Strengths of the Object-Oriented Paradigm
With information hiding, postdelivery maintenance is safer The chances of a regression fault are reduced
Development is easier Objects generally have physical counterparts This simplifies modeling (a key aspect of the object-oriented paradigm)
Well-designed objects are independent units Everything that relates to the real-world object being modeled is in the object — encapsulation Communication is by sending messages This independence is enhanced by responsibility-driven design (see later)
A classical product conceptually consists of a single unit (although it is implemented as a set of modules) The object-oriented paradigm reduces complexity because the product generally consists of
independent units
The object-oriented paradigm promotes reuse Objects are independent entities
Classical Phases vs Object-Oriented Workflows
There is no correspondence between phases and workflows
Classical paradigm
1. Requirements phase2. Analysis (specification) phase3. Design phase4. Implementation phase5. Post-delivery maintenance6. Retirement
Object-Oriented paradigm
1. Requirements workflow2. Object-Oriented Analysis workflow3. Object-Oriented Design workflow 4. Object-Oriented Implementation workflow 5. Post-delivery maintenance6. Retirement
Analysis/Design “Hump”
Structured paradigm: There is a jolt between analysis (what) and design (how)
Object-oriented paradigm: Objects enter from the very beginning
In the classical paradigm Classical analysis
Determine what has to be done Design
Determine how to do it Architectural design — determine the modules Detailed design — design each module
Removing the “Hump”
In the object-oriented paradigm Object-oriented analysis
Determine what has to be done Determine the objects
Object-oriented design Determine how to do it Design the objects
The difference between the two paradigms is shown on the next slide
In More Detail
Objects enter here Modules (objects) are introduced as early as the object-oriented
analysis workflow This ensures a smooth transition from the analysis workflow to
the design workflow The objects are then coded during the implementation workflow
Again, the transition is smooth
Figure 1.9
Figure 1.8
Classical paradigm2. Analysis (specification) phase
• Determine what the product is to do
3. Design phase• Architectural design• Detailed design
4. Implementation phase• Code the modules in an
appropriate programming language.
• Integrate
Object-Oriented paradigm2. Object-Oriented Analysis workflow
• Determine what the product is to do
• Extract the classes3. Object-Oriented Design workflow
• Detailed design4. Object-Oriented Implementation
workflow• Code the modules in an
appropriate OO programming language.
• Integrate
1.10 The Object-Oriented Paradigm in Perspective The object-oriented paradigm has to be used correctly
All paradigms are easy to misuse
When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm
The object-oriented paradigm has problems of its own
The object-oriented paradigm is the best alternative available today However, it is certain to be superceded by something better in the
future
1.11 Terminology
Client, developer, user Internal software Contract software Commercial off-the-shelf (COTS) software Open-source software
Linus’s Law Software Program, system, product Methodology, paradigm
Object-oriented paradigm Classical (traditional) paradigm
Technique
Terminology (contd)
Mistake, fault, failure, error Defect Bug
“A bug crept into the code”
instead of “I made a mistake”
Object-Oriented Terminology Data component of an object
State variable Instance variable (Java) Field (C++) Attribute (generic)
Action component of an object Member function (C++) Method (generic)
C++: A member is either an Attribute (“field”), or a Method (“member function”)
Java: A field is either an Attribute (“instance variable”), or a Method
1.12 Ethical Issues
There is a code of ethics for Software Engineers.
What is an example of where such a code might be necessary?
IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice
http://www.acm.org/constitution/code.html