CODE

INTRODUCTION TO SOFTWARE
ENGINEERING
Engr. Njawe Edouard
Cloud engineer/Community Developer
Lecture 1: Welcome, and Introduction
[email protected]
*This course aim to produce graduates that:
Are able to build and integrate complex systems
Understand software engineering issues such as:
* Configuration management
* Effort estimation
* Subcontracting
* Verification and validation
* Software integration
* Maintenance
* Negotiate with others to procure and distribute
software
* Adhere to software specifications and module
interfaces
* Develop efficient and correct code
* To be able to work independently.
*By the time students finish this course they
should have real-world experiences that will
see them well placed to get employment .
*Students should be able to talk to employers
about the problems and issues involved in
building large complex systems.
…
*The course will consist of lectures, tutorials (an out of lab
“in-lab” small group discussion session) and a large
project with several deliverables – more on this soon.
*The courses require verbal presentations and written
documentation to be produced.
*The project is large and offers the opportunity to
utilize knowledge you have gained in other subjects,
especially those related to programming, data
structures and algorithms.
* Indeed your general knowledge of computer science will
typically shape the design and implementation of the
solution you produce.
* Assessment is based on:
* Assignment (40%)
* Quizzes (10%)
* Midterm exam (20%)
* Final exam (30%)
* A serious attempt must be may at each component.
* In particular, a 60% average across each of the following is required to
pass the subject:
* Quizzes
* Project/assignments
* Exams
* There are no fixed textbooks for this course. Like real-life, you
need to decide if you need one, and if so, which book best suits
you.
* We recommend the following as good books that cover the much
(but not all) of the lecture material.
* Robert Glass, “Facts and Fallacies of Software Engineering”,
Addison-Wesley.
* Evelyn Stiller & Cathie LeBlanc, “Project-Based Software
Engineering”, Addison-Wesley.
* Erich Gamma et al, “Design Patterns. Elements of Reusable
Object-Oriented Systems”, Addison-Wesley.
* John Bentley, “Programming Pearls”, Addison-Wesley
* Other books that are worth looking at include:
* Roger Pressman, “Software Engineering. A
Practitioner’s Approach”, McGraw-Hill
* Ian Sommerville, “Software Engineering”,
Addison-Wesley
* Stephen Schach, “Classical and Object-
Oriented Software Engineering”, McGraw-Hill
* Shari Pfleeger, “Software Engineering. Theory
and Practice”, Prentice-Hall
*The final exam will be held in two parts at the regular
lecture times the week before the traditional exam
week.
*The time slot during exam week will be used to go
through the exam and discuss solutions.
* Ask questions
* Interact with the instructors
* Use each other as a resource
* Exchange ideas
* Experiment
* You should take notes in lectures – the slides are
merely our notes and may sometime be terse!
*The assignments will have firm deadlines.
*Significant grades are lost for being late – 20% of the
available marks each day or part thereof.
*Very much like a penalty clause in a contract.
*Deadlines will be at a specific time and late penalties
applies from 1 second past the deadline. The system
clock on esus will be treated as the official clock for the
course.
*No excuses will be accepted – including machine failure,
busy labs, …
Introduction of Software Engineering
Need of Software Engineering
Characteristics of a Good Software
Nature of Software
Software process
SDLC Model
A Physician, a Civil Engineer
and a Computer Scientist were
arguing about what was the
oldest profession in the world.
*The Physician remarked,
"Well, in the Bible, it says that God
created Eve from a rib taken out of
Adam. This clearly requires surgery,
and so I can rightly claim that mine is
the oldest profession in the world."
*The Civil Engineer interrupted, and said,
" But even earlier in the book of Genesis, it
states that God created the order of the
heavens and the earth from out of the
chaos. This was the first and certainly the
most spectacular application of civil
engineering. Therefore, fair doctor, you
are wrong; mine is the oldest profession in
the world.“
*The Computer Scientist leaned back in the
chair, smiled and then said confidently,
"Ah, but what do you think created
the chaos ? "
*The term software engineering is
composed of two words, software and
engineering.
Software is more than just a program code. A
program is an executable code, which serves
some computational purpose. Software is
considered to be a collection of executable
programming code, associated libraries and
documentations. Software, when made for a
specific requirement is called software
product.
*Engineering on the other
hand, is all about
developing products, using
well-defined, scientific
principles and methods.
*So, we can define software engineering as an
engineering branch associated with the development of
software product using well-defined scientific principles,
methods and procedures. The outcome of software
engineering is an efficient and reliable software
product.
*The application of a systematic,
disciplined, quantifiable approach to the
development, operation and maintenance
of software.
*The need of software engineering arises because of
higher rate of change in user requirements and
environment on which the software is working.
Large software - It is easier to build a wall than to a
house or building, likewise, as the size of software
become large engineering has to step to give it a
scientific process.
*Scalability- If the software process were not based on
scientific and engineering concepts, it would be easier to
re-create new software than to scale an existing one..
* Cost- As hardware industry has shown its skills and huge
manufacturing has lower down the price of computer and
electronic hardware. But the cost of software remains high if
proper process is not adapted.
* Dynamic Nature- The always growing and adapting nature
of software hugely depends upon the environment in which
the user works. If the nature of software is always changing,
new enhancements need to be done in the existing one. This
is where software engineering plays a good role.
* Quality Management- Better process of software
development provides better and quality software product
*A software product can be judged by what it offers
and how well it can be used. This software must
satisfy on the following grounds
*Operational
*Transitional
*Maintenance
*Well-engineered and crafted software is
expected to have the following
characteristics:
This tells us how
well software works *Correctness
in operations. It can *Functionality
be measured on:
*Budget *Dependability
*Usability *Security
*Efficiency *Safety
*This aspect is important when the software
is moved from one platform to another:
*Portability
*Interoperability
*Reusability
*Adaptability
This aspect briefs about how well a
software has the capabilities to maintain
itself in the ever- changing environment:
*Modularity
*Maintainability
Flexibility
*Scalability
*In short, Software engineering is a branch
of computer science, which uses well-
defined engineering concepts required to
produce efficient, durable, scalable, in-
budget and on-time software products.
Software Development Life Cycle (SDLC) is a well-
defined, series of steps or stages or phases taken in
software engineering to design and build a software
product.
SDLC provides a series of steps to be
followed to design and develop a software
product efficiently. SDLC framework
includes the following steps:
* The communication phase encompasses crucial activities that
support effective collaboration, clear understanding, and
seamless information exchange among project stake holders,
including developers, clients, and end users. Here are some
activities in the communication phase of the SDLC:
*Engaging in discussions and interviews
with stakeholders, including clients, users,
and subject matter experts, to understand
their needs, preferences, and pain points.
This helps in gathering initial project
requirements and expectations.
*Facilitating open channels for ongoing
feedback and iterative discussions with
stakeholders to refine and validate
requirements. Regular communication
ensures that changes can be incorporated
in timely manner.
*Translating gathering information into
clear and comprehensive documentation,
such as requirement specifications, user
stories, and use cases. This
documentation serves as reference point
for the entire development team.
*Regularly communicating project progress
and updates to stakeholders through
status reports, demonstrations, or
meetings. Transparent communication
about achievable milestones and potential
challenges is vital for maintaining
stakeholder trust.
*Clearly articulating underlying
assumptions, dependencies, and
constraints to ensure that all stakeholders
have a shared understanding of the
project scope, limitations and strategic
goals.
*Establishing a process for evaluating and
addressing change requests effectively.
This involves communicating potential
impacts of changes in terms of scope,
timeline, and resources and obtaining
stakeholder approval when neccesssary.
*Identifying potential risk and uncertainties
associated with the project and engaging
stakeholders in discussions to develop
mitigation strategies and contingency
plans.
*Involving end users in validation and
acceptance testing, as well as capturing
their feedback to ensure that the software
meets their needs and expectations.
*Addressing conflicts and managing issues
that arise during the development process
through effective communication and
negotiation. This ensures that
stakeholders remain aligned and engaged
*Communicating project closure activities,
conducting handover processes, and
ensuring knowledge stakeholders for on-
going maintenance and support.
*Effective communication through out the
SDLC helps ensure that all involved parties
are aligned, leading to a shared
understanding of objectives, requirements,
and progress. It fosters collaboration,
reduces misunderstandings, and ultimately
contributes to the successful delivery of
software projects.
* After requirement gathering, the team comes up
with a rough plan of software process. At this step
the team analyzes if the software can be made to
fulfill all requirements of the user and if there is
any possibility of the software being no more
useful. If the project is financially, practically and
technologically feasible for the organization to
take up, they take up the project else they let it
go.
* At this step the developers decide a roadmap of their
plan and try to bring up the best software model
suitable for the project. System analysis includes
understanding of software product limitations, learning
system related problems or changes to be done in
existing systems beforehand, identifying and
addressing the impact of project on organization and
personnel etc. The project team analyzes the scope of
the project and plans the schedule and resources
accordingly.
*Next step is to bring down whole knowledge of
requirements and analysis on the desk and
design the software product. The inputs from
users and information gathered in requirement
gathering phase are the inputs of this step. The
output of this step comes in the form of two
*
*designs; logical design and physical
design. Engineers produce meta-data and
data dictionaries, logical diagrams, data-
flow diagrams and in some cases pseudo
codes.
*This step is also known as programming
phase. The implementation of software
design starts in terms of writing program
code in the suitable programming
language and developing error-free
executable programs efficiently.
* An estimate says that 50% of whole software
development process should be tested. Errors may ruin
the software from critical level to its own removal.
Software testing is done while coding by the
developers and thorough testing is conducted by
testing experts at various levels of code such as
module testing, program testing, product testing, in-
house testing and testing the product at user’s end.
Early discovery of errors and their remedy is the key to
reliable software.
*Software may need to be integrated with
the libraries, databases and other
program(s). This stage of SDLC is involved
in the integration of software with outer
world entities.
*This means installing the software on user
machines. At times, software needs post-
installation configurations at user end.
Software is tested for portability and
adaptability and integration related issues
are solved during implementation.
* This phase confirms the software operation in terms of
more efficiency and less errors. If required, the users are
trained on, or aided with the documentation on how to
operate the software and how to keep the software
operational. The software is maintained timely by updating
the code according to the changes taking place in user end
environment or technology. This phase may face
challenges from hidden bugs and real-world unidentified
problems.
*As time elapses, the software may decline on the
performance front. It may go completely obsolete or
may need intense up gradation. Hence a pressing
need to eliminate a major portion of the system
arises. This phase includes archiving data and
required software components, closing down the
system, planning disposition activity and terminating
system at appropriate end-of-system time.
* The development team must identify a suitable life
cycle model for the particular project and then
adhere to it. Without using of a particular life cycle
model the development of a software product would
not be in a systematic and disciplined manner.
When a software product is being developed by a
team there must be a clear understanding among
team members about when and what to do.
Otherwise it would lead to chaos and project failure.
* This problem can be illustrated by using an example.
Suppose a software development problem is divided into
several parts and the parts are assigned to the team
members. From then on, suppose the team members
are allowed the freedom to develop the parts assigned
to them in whatever way they like. It is possible that one
member might start writing the code for his part,
another might decide to prepare the test documents
first, and some other engineer might begin with the
design phase of the parts assigned to him.
This would be one of the perfect recipes for project
failure. A software life cycle model defines entry and
exit criteria for every phase. A phase can start only if
its phase-entry criteria have been satisfied. So
without software life cycle model the entry and exit
criteria for a phase cannot be recognized. Without
software life cycle models it becomes difficult for
software project managers to monitor the progress of
the project.
*The software development paradigm helps developer to
select a strategy to develop the software. A software
development paradigm has its own set of tools,
methods and procedures, which are expressed clearly
and defines software development life cycle. A few of
software development paradigms or process models are
defined as follows
*Classical waterfall model is the simplest model of
software development paradigm. It says all the phases of
SDLC will function one after another in linear manner.
That is, when the first phase is finished then only the
second phase will start and so on.
*This model consists of a linear and sequential
approach, where progress flows steadily
downwards through the phases of conception,
initiation, analysis, design, construction,
testing, deployment and maintenance. Each
phase is typically viewed as a distinct step
with its own goals and deliverables, the output
of one feeding into the input of the next.
*This model assumes that everything is carried out and
taken place perfectly as planned in the previous stage
and there is no need to think about the past issues
that may arise in the next phase. This model does not
work smoothly if there are some issues left at the
previous step. The sequential nature of model does
not allow us go back and undo or redo our actions.
*This model is best suited when developers
already have designed and developed
similar software in the past and is aware
of all its domains.
*The waterfall model follows a linear and
sequential process, with each phase
dependent on the deliverables of the
previous phase. Sequential progression is
emphasized, typically without overlap or
iterative between phases
*The model encourages extensive
documentation at each stage, with an
emphasis on creating comprehensive
specifications and design documentation
before moving to the next phase.
*The waterfall model is less adaptable to
changes in requirements or scope, as
modifications late in the development
process can be complex and costly to
implement.
*Projects: It is best suited for projects with
well-defined, stable, and unchanging
requirements where the end product has
a predictable structure.
*The model provides clear milestones and
deliverable points for project management
and client review, facilitating
accountability.
*Its important to note that while the
waterfall model has been widely used
historically, it is less commonly software
development due to its limitations
regarding adaptability and the potential
for late-stage design changes.
*The waterfall model offers a disciplined
and well-organized step-by-step approach,
enabling clear documentation and
traceability throughout the project life
cycle.
*The phased nature of the waterfall model
provides high visibility into the entire
project, giving stakeholders a clear
understanding of the process, milestones
and deliverables.
*With well-defined and sequential phases,
project management becomes more
straightforward as specific requirements
and tasks are mapped to each phase
*The linear nature of the model allows for
better resource allocation and planning,
as each phase has specific responsibilities
and resource requirements.
*Clear Milestones and deliverables enable
clients to provide feedback and validation
at key points in the project life cycle
*The model is less adaptable to changes in
requirements or scope mid-project, as
modifications late in the development
process can be complex and costly to
implement.
*Late stage client validation and feedback
might result in substantial rework if
requirements are misunderstood or
misinterpreted.
*The linear progression from one phase to
another can lead to longer delivery times,
especially if changes are required late in
the project.
*Waiting until the end of the development
process for testing and validation may
result in late discovery of issues, which
may be more difficult and costly to
address
*The model poses higher risks for projects
where requirements are subject to change
or evolve, as it lacks inherent flexibility in
accommodating evolving needs
*Understanding these strengths and
limitations is crucial in determining the
suitability of waterfall model for a
particular project or organization. Many
modern development methodologies ,
such as Agile, have emerged to address
some of the waterfall model’s limitations
*This model leads the software
development process in iterations. It
projects the process of development in
cyclic manner repeating every step after
every cycle of SDLC process.
* The software is first developed on very small scale
and all the steps are followed which are taken into
consideration. Then, on every next iteration, more
features and modules are designed, coded, tested
and added to the software. Every cycle produces a
software, which is complete in itself and has more
features and capabilities than that of the previous
one.
*
After each iteration, the management team
can do work on risk management and
prepare for the next iteration. Because a
cycle includes small portion of whole
software process, it is easier to manage the
development process but it consumes more
resources.
* A prototype is a toy implementation of the system. A prototype
usually exhibits limited functional capabilities, low reliability, and
inefficient performance compared to the actual software. A
prototype is usually built using several shortcuts. The shortcuts
might involve using inefficient, inaccurate, or dummy functions. The
shortcut implementation of a function, for example, may produce
the desired results by using a table look-up instead of performing
the actual computations. A prototype usually turns out to be a very
crude version of the actual system.
1. Basic Requirement Identification: This step involves
understanding the very basic product requirements
especially in terms of user interface. The more intricate
details of the internal design and external aspects like
performance and security can be ignored at this stage.
2. Developing the initial Prototype: The initial Prototype is
developed in this stage, where the very basic requirements
are showcased and user interfaces are provided. These
features may not exactly work in the same manner
internally in the actual software developed and the
workarounds are used to give the same look and feel to the
customer in the prototype developed.
3. Review of the Prototype: The prototype developed is then
presented to the customer and the other important
stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in
the product under development.
4. Revise and enhance the Prototype: The feedback and
the review comments are discussed during this stage and
some negotiations happen with the customer based on
factors like, time and budget constraints and technical
feasibility of actual implementation. The changes accepted
are again incorporated in the new Prototype developed
and the cycle repeats until customer expectations are met.
*The Spiral model of software development is
shown in fig.5. The diagrammatic
representation of this model appears like a
spiral with many loops. The exact number of
loops in the spiral is not fixed. Each loop of
the spiral represents a phase of the software
process. For example, the innermost loop
might be concerned with feasibility study.
*The next loop with requirements
specification, the next one with design,
and so on. Each phase in this model is
split into four sectors (or quadrants) as
shown in the fig bellow. The following
activities are carried out during each
phase of a spiral model.
*First quadrant (Objective Setting)
* During the first quadrant, it is needed to identify the objectives of the
phase.
* Examine the risks associated with these objectives.
*Second Quadrant (Risk Assessment and Reduction)
* A detailed analysis is carried out for each identified project risk.
* Steps are taken to reduce the risks. For example, if there is a risk that
the requirements are inappropriate, a prototype system may be
developed.
*Third Quadrant (Development and
Validation)
* Develop and validate the next level of the
product after resolving the identified risks.
*Fourth Quadrant (Review and
Planning)
* Review the results achieved so far with the
customer and plan the next iteration around
the spiral.
* Progressively more complete version of the
software gets built with each iteration around
the spiral.
Suppose user enters URL www.cs.uiuc.edu/ (contains text,
references to 10
jpeg images)
1a. http client initiates a TCP 1b. http server at host www.cs.uiuc.edu
connection to http server waiting for a TCP connection at port
(process) at www.cs.uiuc.edu. 80. “accepts” connection, notifying
Port 80 is default for http server. client
2. http client sends a http request message
(containing URL) into TCP
connection socket 3. http server receives request messages,
forms a response message containing
requested object (index.html), sends
message into socket

time
 4. http server closes the TCP connection
5. http client receives a (if necessary).
response message
containing html file, displays
html, Parses html file, finds
6.10 referenced
Steps jpeg objects
1-5 are then repeated for each of
10 jpeg objects

time For fetching referenced objects, have 2 options:

* non-persistent connection: only one object fetched per TCP
connection
* some browsers create multiple TCP connections simultaneously - one per
object
* persistent connection: multiple objects transferred within one TCP
connection
1. Telnet to your favorite WWW server:

telnet www.google.com 80Opens TCP connection to port 80

(default http server port) at www.google.com
Anything typed in sent
to port 80 at www.google.com
2. Type in a GET http request:
GET /index.html By typing this in (may need to hit
Or return twice), you send
GET /index.html HTTP/1.0 this minimal (but complete)
GET request to http server
3. Look at response message sent by http server!
What do you think the response is?
 A distributed system is a collection of entities, each of which is
autonomous, programmable, asynchronous and failure-prone,
and that communicate through an unreliable communication
medium.

*Entity=a process on a device (PC, PDA)

*Communication Medium=Wired or wireless network
*Our interest in distributed systems involves
* design and implementation, maintenance, study, algorithmics
* No global clock; no single global notion of the correct time
(asynchrony)
* Unpredictable failures of components: lack of response may be
due to either failure of a network component, network path
being down, or a computer crash (failure-prone, unreliable)
* Highly variable bandwidth: from 16Kbps (slow modems or
Google Balloon) to Gbps (Internet2) to Tbps (in between DCs of
same big company)
* Possibly large and variable latency: few ms to several seconds
* Large numbers of hosts: 2 to several million
*
*
* Real distributed systems
* Cloud Computing, Peer to peer systems, Hadoop, key-value stores/NoSQL, distributed
file systems, sensor networks, measurements, graph processing, stream processing, …
* Classical Problems
* Failure detection, Asynchrony, Snapshots, Multicast, Consensus, Mutual Exclusion,
Election, …
* Concurrency
* RPCs, Concurrency Control, Replication Control, …
* Security
* Byzantine Faults, …
* Others…
*
*Common Goals:
* Heterogeneity – can the system handle a large variety of types of PCs
and devices?
* Robustness – is the system resilient to host crashes and failures, and to
the network dropping messages?
* Availability – are data+services always there for clients?
* Transparency – can the system hide its internal workings from the users?
* Concurrency – can the server handle multiple clients simultaneously?
* Efficiency – is the service fast enough? Does it utilize 100% of all
resources?
* Scalability – can it handle 100 million nodes without degrading service?
(nodes=clients and/or servers) How about 6 B? More?
* Security – can the system withstand hacker attacks?
*If you’re already complaining that the list of topics we’ve
discussed so far has been perplexing…
* You’re right!
* It was meant to be (perplexing)

*The Goal for the Rest of the Course: see enough examples
and learn enough concepts so these topics and issues will
make sense
* We will revisit many of these slides in the very last lecture of the
course!
* Which of the following inventions do you
think is the most important?
1. Car
2. Wheel
3. Bicycle

“What lies beneath?” Concepts!

All this information contained in handout on course website:
“Course Information and Schedule”
* Web: courses.engr.illinois.edu/cs425/
* Textbook, Recommended but not Required
* Colouris, Dollimore, Kindberg and Blair (5th edition)
* CDK Textbook
* Lectures
* Homeworks
* Approx. one every two-three weeks
* Solutions need to be typed, figures can be hand-drawn
* May have extra problems for 4-credit students
* Programming assignments (3-4)
* Exams/quizzes
* From this semester onwards: Recommended but not
required
* Text: Colouris, Dollimore, Kindberg and Blair (5th edition).

* We will refer to section, chapter, and problem numbers only

in the 5th edition.
* Older editions may have a different numbering for some HW
problems (that we give from the textbook). Make sure you solve
the right problem; the responsibility is yours (no points for
solving the wrong problem!)
* Lectures
* lecture slides will be placed online at course website
* “Tentative” version before lecture
* “Final” version after lecture
* Homeworks – office hours and discussion forum to help you
(without giving you the solution).
* Programming Assignments (MPs) – First two assignments will be in
C
* Office hours and Piazza discussion forum to help you (without giving you the
solution).

* Course Prerequisite: CS 241 or ECE 391 or equivalent

OS/networking course (latter need instructor permission)
In person:
* Myself (Indy): 3112 Siebel Center
* Office Hours Every Tuesday and Thursday right after class – see website

* TAs:
* Le Xu
* Hongwei Wang
* Rajath Subramanyam
* Ana Gainaru
(Check course website for office hours. There is > 0 office hours every day of the week.)
Virtually:
* Discussion Forum: Piazza (most preferable, monitored daily) – 24 hour turnaround time for
questions!
* Email (turnaround time may be longer than Piazza) – use [email protected]
* Email individuals (instructor, TA) only if absolutely necessary (e.g., private matter)
*(Reading for today’s lecture: Relevant parts of Chapter
1)
*All students: Go to course website and fill out Student
Survey sheet
* https://courses.engr.illinois.edu/cs425/
* Fill by this Thursday (8/28)
*Not yet registered? Fill out Waitlist form at website.
*Next lecture
* Topic: “Introduction to Cloud Computing”