2. Muhammad Naveed Zafar
Educational Background
BS in Computer Science
(Bahria University)
MS in Software Project
Management
(FAST University)*
Professional Experience
Project Manager
(NevTech)
Faculty Member
(Aptech MSG)
Project Coordinator
AMI
Software Engineer
GoSafe Systems
3. Agenda
What, Why and Aspects of Software Engineering ?
Horror Software Failure Stories
Software Engineer Line of Actions
Software Engineering Stakeholders
Engineering Approach
Roles and Members of Development Team
Problem Solving Paradigms
SDLC Models
Best Practices to be Adopt
Scrum Methodologies
4. What is software?
• Computer programs and associated documentation
• Software products may be developed for a particular
customer or may be developed for a general market
• Software products may be
– Generic/COTS - developed to be sold to a range of
different customers
– Custom- developed for a customer according to their
specification
5. What is Engineering?
• Engineering is …
– The application of scientific principles and methods to the
construction of useful structures.
Examples:
– Mechanical engineering
– Computer engineering
– Civil engineering
– Chemical engineering
– Electrical engineering
– Nuclear engineering
– Aeronautical engineering
6. What Actually “Software Engineering”?
• A discipline whose aim in the production of software that
– meets the client‟s needs
– fault-free
– delivered on time
– delivered within budget
– easy to modify
7. Why the need for Software Engineering?
Software Crisis: Unacceptable low quality of software,
exceeds deadline and budget.
Canceled, 23%
Successful,
28%
*Completed with
Faults, 49%
*Completed late, over budget, and/or with features missing
8. Why Software Engineering ?
• The problem is complexity
• Many sources, but size is a key:
– Mozilla contains 3 Million lines of code
– UNIX contains 4 million lines of code
– Windows 2000 contains 108 lines of code
• Second is roles define
• Third is uncertainty of “inputs” and their timing
• Fourth is the continuing changing “environment” and demands.
Software engineering is about managing all the sources of complexity to
produce effective software.
9. Software Engineering Aspects
• Historical Aspects:
– , a NATO group coined the term “Software Engineering”
– NATO Software Engineering Conference concurred that
“Software production should be an engineering-like activity”
– Using philosophies and paradigms of established engineering
disciplines to solve Software Crisis that the quality of software was
generally unacceptably low and that deadlines and cost limits were
not being met”
10. • Economic Aspects
– Software Engineering v.s. Computer Science
• The computer scientist investigates several ways to produce
software, some good and some bad
• But the software engineer is interested in only those techniques
that make sound economic sense.
For example: A coding technique that can execute very efficiently
but with higher maintenance cost may not be a good choice, since
maintenance occupies a lot of resources of the whole life cycle.
Software Engineering Aspects…
11. • Maintenance Aspects
– Software Life Cycle / Software Process
• Requirements Phase
• Specification (Analysis) Phase
• Planning Phase
• Design Phase
• Implementation Phase
• Integration Phase
• Maintenance Phase highest cost among all these phases)
• Retirement
Software Engineering Aspects…
12. Requirement 2%
Specification 4%
Planning 1%
Design 6%
Module Coding 5%
Module Testing 7%
Integration 8%
Maintenance
67%
Maintenance Aspects
Maintenance
Approximate relative costs
of the phases of the software
life cycle.
Maintenance is so important that a major aspect of software
engineering consists of techniques, tools, and practices that lead to a
reduction in maintenance cost
13. Horror Software Failure Stories
• Patients died as a consequence of severe overdoses of
radiation.
• US Treasury Department mailed incorrectly printed Social
Security Checks.
• Interest miscalculated on student loans resulting in higher
monthly payments.
• Mars Climate Orbiter spacecraft crashes into the surface of
Mars because of measurement conversion error.
Consequences of software failures range from inconvenience to death!
14. Software Engineer Line of Actions
Software Engineers should
– adopt a systematic and organised approach to all aspects
of software development.
– use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
• the resources available
– Understand and communicate processes for improved
software development within their organization
– Be effective team members and/or leaders.
– Can be very technical or more managerial depending on
organizational need.
15. Where Does the Software Engineer Fit In?
• Computer Science: focusing on computer
hardware, compilers, operating systems, and programming
languages
• Software Engineering: a discipline that uses computer and
software technologies as a problem-solving tools
16. Where Does the SW Engineer Fit in?...
Relationship between Computer Science and Software Engineering
17. Qualities of Good Software?
• Good software engineering must always include a strategy
for producing quality software
• Three ways of considering quality
– The quality of the product
– The quality of the process
– The quality of the product in the context of the business
environment
18. Who Does Software Engineering?
• Customer: the company, organization, or person who pays
for the software system
• Developer: the company, organization, or person who is
building the software system
• User: the person or people who will actually use the system
19. Who Does Software Engineering? (continued)
Participants (stakeholders) in a software development project
20. Engineering Approach
Building a System
• Requirement analysis and definition
• System design
• Program design
• Writing the programs
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance
21. Members of the Development Team
• Requirement Analysts: work with the customers to identify and document the
requirements
• Designers: generate a system-level description of what the system us
supposed to do
• Programmers: write lines of code to implement the design
• Testers: catch faults
• Trainers: show users how to use the system
• Maintenance Team: fix faults that show up later
• Librarians: prepare and store documents such as software requirements
• Configuration Management Team: maintain correspondence among various
artefacts.
22. Members of the Development Team
(continued)
Typical roles played by the members of a development team
24. Problem Solving Paradigms
Several techniques have been suggested to help solve the software
crisis
– ~ - : Structured Paradigm
• Structured Systems Analysis, Composite/Structured Design, Structured
Programming, Structured Testing
• Lead to major improvements for software industry
• But only good for small programs (say, , - , lines of codes)
• Not so good in software maintenance aspects, (for instance, because of the
separation of action-oriented and data-oriented in structured paradigm)
– Object-Oriented Paradigm
• An object is a unified software component that incorporates both data and
actions that operate of those data --> More Promising!
25. Why use Object Oriented Paradigm?
• Classical Structured Paradigm
– Focus on functions of system
• Object-Oriented Paradigm
– Focus on objects
– Implementation details are local to the object
• Regression fault (fault produced by seeming unrelated change) is
greatly reduced.
– Encapsulation: well-designed independent units
– Potential Reuse of objects reduces time and cost
26. The Software Process
• A structured set of activities required to develop a software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract representation of a process.
• It presents a description of a process from some particular perspective.
28. Waterfall Model Characteristics
• The classic life cycle - oldest and most widely used paradigm
• Activities „flow‟ from one phase to another
• If there are corrections, return to a previous phase and „flow‟ from
there again
• Major advantages: Good for planning and well defined/repeated projects
29. Problems of Waterfall Model
• Real projects often follow the sequence
• All requirements may not be stated explicitly by customer
• Customer only sees the results after some time
• Developers are often delayed at certain phases
30. Rapid Application Development (RAD)
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
Team #1 Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
Team #2
Time period
31. RAD Characteristics
• “High-speed” version of waterfall model
• Primarily for information systems applications
• Requirements well-understood, fully functional system produced in
short time
• The application modularized - major functions can be completed in 3
months
• Separate teams complete the functions, then integrated as a whole
• Requires human resource and commitment
33. Importance of Continual Planning,
Testing, Documentation
• After customer has signed off on the specifications, continue to monitor
and adjust plan.
• Software must be fault-free as possible at all times.
• At all times, documentation must be complete, correct and up-to-date.
– personnel overturn
– incomplete implementation
– inaccurate testing
– impossible to maintain
34. Conclusion
• Tips to Solve a problem
– Analyse Problems
– Synthesize a solution
• Understand that requirements may change
• Must view quality from several different perspectives
• Use fundamental software engineering concepts
• Keep system boundary in mind
Short for commercial off-the-shelf, an adjective that describes software or hardware products that are ready-made and available for sale to the general public