Lecture #1

 What should a CS student know

 Foundational (Computer science)
1. Basic programming skills
2. Problem solving (algorithm analysis , well known alg.)
3. Data structures
4. Math (Probability, Discrete math, algorithm analysis)

 Software Engineering
1. OOP
2. Design patterns
3. Agile (methodology)
4. Unit testing

 Man-Month issue
man-month What a person finishes in a month is not necessarily done by two in half month !
(difficulty of adding more people to cut time)
Tar pit Development teams can get stuck at a point and cannot proceed similar to animals in tar
‫حفرة القطران‬ pit (project fails)
(projects can easily reach a freezing point and fail)
Social loafing The phenomenon of a person exerting less effort to achieve a goal when they work in a
‫ر‬
‫التاخيياالجتماعي‬ group than when working alone.
this is mostly applicable when their individual contribution to the goal isn’t apparent.
Ringlemann The tendency for individual members of a team to become increasingly less productive as
effect the size of the team increases‫يعالقةيعكسيةيبيييعد يديالفريقيوالمجهو يديالمبذولي‬
Two pizzas rule Bigger teams may not help

 What is software engineering ?

Engineering problem how to solve economically under constraints
the process of solving customer problems by systemic development and evaluation of
Software large high quality software systems within cost , time and other constrains
engineering The systematic activities involved in the design, implementation, and testing of software
to optimize its production and support

 Software engineering include many concepts:

Methodology Tools (automation) Practices Testing
 Why software projects fail ?
Bad estimates of time and money (estimation is very tough activity)
Traditional project management doesn’t fit with software engineering projects because Software is
difference and complex and The Solution is Agile method instead of plan-driven (waterfall)
 Lecture #2
 Waterfall vs. Agile
 Agile methods: is a proposed solution to increase the
chance of a successful software project
 Agile projects are three times more successful than
waterfall projects

 Why software is different? (Characteristics that make it different)

 Software is complex
1. Complexity grows as number of components (instructions or lines of code) increases
2. Software complexity is not just because of the instructions but also caused by
interactions between such instructions
Complexity = number of interactions … n(n-1)/2 (n: lines of codes)
Example 1 Example 2

 Program of 100,000 lines is more complex

 A program of 6 lines: complexity = 6*5/2 = 15
By how much = (100,000*99999)/(10,000*9999) = 100
 A program of 12 lines: complexity = 12*11/2 = 66
times more complex than program of 10,000 lines
 Program of 12 lines is more complex ,By how much =
66 / 15 = 4.4 times complex than program of 6 lines
Conclusion: Complexity of software increases much faster than its size

3. developer deal with this complexity issue by Reducing complexity

The key to reduce complexity is by dividing the program to smaller components (make functions)

 Complexity of each small square = 3*2/2 = 3

 Complexity of all small squares = 3*4 = 12
 Complexity of big square = 4*3/2 = 6
 Total Complexity = 12 + 6 = 18
 Example 3
 f1 (5 statements): complexity = 5*4/2 = 10
 f2 (8 statements): complexity = 8*7/2 = 28
 f3 (5 statements): complexity = 5*4/2 = 10
 main (7 statements): complexity = 7*6/2 = 21
 Four Functions: complexity = 4*3/2 = 6
Total Complexity = 10 + 28 + 10 + 21 + 6 = 75

 Software is abstract
1. Dividing code to modules reduces the complexity but make software more abstract
2. Accurate software behavior can only be seen at individual instruction level.
3. At higher levels, many details are hidden, with hidden things developers can easily assume things
that are not accurate and the result is a program not doing what we expect
4. Difficult for development team to follow the plan

 Clean code
 What makes a good programmer?
Good programmers who write code that humans can understand
 Clean code: is code that is easy to understand and easy to change
 Clean code secret: NAMES
easily pronounceable names names show intention
 Lecture #3
 Why software is different ?
 Characteristics based on Software nature
1. Software is complex
2. Software is abstract

 Characteristics based on technology used in software production

1. Technology changes rapidly
2. Technology is a vast domain
3. Best practices are not mature
4. Technology experience is incomplete
5. Repetitive work is automated

 Characteristics based on how customers interact with development team

1. Requirements are incomplete
2. Change is considered easy
3. Change is inevitable ‫حتمي‬
 Lecture #4
 Incremental (Agile) vs. Iterative (Waterfall)
 Incremental development: focuses on building software in distinct stages,
adding features incrementally.
 Iterative development: is a process where software is developed in
successive cycles, with each cycle building upon the previous one

 What exactly is agile manifesto methodology ?

1. Rapid software development
2. Incremental software development
3. “The ability to create and respond to change” (Agile Alliance)
4. Mindset and way of thinking
5. Umbrella term for a set of different methods

 Four Agile values

1. Individuals and interactions over process and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract neglection
4. Responding to change over following a plan

 Agile methods and 12 Agile Principles

Agile methods 12 Agile Principles

Constant Pace ‫وتية ثابتة‬

‫ر‬
running at a fixed pace for the duration of a run

 Agile misconceptions
1. Agile not excuse to stop documentation
2. Not an opportunity to eliminating planning
3. Many people are into agile without knowing it

 Pair programming
1. Better for refactoring and less errors
2. Avoiding isolated experience
3. productivity is comparable to individual programming
 Lecture #5
 Some Agile methods
 Crystal (very descriptive) ‫كبتيللخطواتيومرونة‬
‫فيهيايوصفي ي‬
 Scrum (most widely used and successful method)
 XP (Extreme Programming) (prescriptive ‫طريقةيشغليمحددةيا يوياجباريهيفييبعضيالخطوات )إلزامي‬

 Main Agile Principles

 Requirements in waterfall and agile

 Waterfall is specification-based process , lengthy and delivery to
customer is long after specification
 Producing useful software quickly is the reason why agile methods
 In agile, processes of specification, design, and implementation are
interleaved ‫( متداخلة‬no detailed system specification in advance)
In agile, we use user stories
 In practice, plan-driven processes are often used with agile
programming practices. to allocate requirements and then plan the
design and development as a series of increments

 User Story Structure

‫معايتيالقبول‬
‫ي‬
  Scrum
1. The most widely used and successful agile methodology.
2. Focus on providing a framework for agile project organization.
3. Does not mandate ‫الييفرض‬ ‫ ي‬use of specific development practices such as pair programming,
more easily integrated with company practices.
4. An increment (cycle) in scrum is called a sprint (1 to 4 weeks)‫ي‬last a fixed length of time and can
never be extended.
5. A sprint cycle starting point is a product backlog (list of things to be done by the team; product
features, requirements, improvements, bugs).
6. Initial product backlog can be derived from a requirements document or a list of user stories.

 Scrum Methodology

‫ر‬
‫الحاجاتيالتيتتميمناقشتها‬

 Scrum terminology ‫مصطلحات‬

Developer self-organizing group of software developers, shouldn’t be more than 7 people.
team Responsible for software and documentation.
Potentially
shippable Software increment that is delivered from a sprint.
product It should be in a finished state and no further work.
increment
Product List of “to do” items for scrum team.
Backlog They can be feature definitions, software requirements, user stories.
Product individual or possibly a small group whose job is to identify product features and
Owner requirements, make priorities and continuously review the product backlog to ensure the
project continues to meet critical business needs.
Scrum A daily meeting of scrum team that reviews progress and prioritizes work to be done
Should be a short face-to-face meeting including the whole team.
ScrumMaster Responsible for ensuring scrum process is followed and guides the team using scrum.
Sprint A development iteration, Sprints are usually 2 to 4 weeks long (Unit of sprint is Week)
Velocity An estimate of how much product backlog effort a team can cover in a single sprint.
Provides a basis for measuring improving performance. (ScrumMaster Role)
 Standup Meeting

 Distributed scrum

 Things that people like about scrum

1. Product is divided into a set of manageable and understandable pieces that stakeholders can
understand.
2. Unstable requirements don’t hold up progress.
3. The whole team sees everything and team communication and morale are improved.
4. Customers see on-time delivery of increments and gain feedback on how the product works. No last-
minute surprises.
5. Trust between customers and developers is established, a positive culture is created in which
everyone expects the project to succeed.
 Lecture #6
 Crystal methodologies
1. A family of methods depending on the size of the project‫ي‬developed by Alistair Cockburn
Alistair did not believe in a one-size-fits-all method
Teams of different sizes need different strategies
1) Crystal clear: 2-8 developers
2) Crystal yellow: 9-20 developers
3) Crystal orange: 21-50 developers
2. “Every project is a game” Each project has unique characteristics and requires custom-tailored
‫ مصممةيخصيصا‬practices and policies
3. Goal of Crystal aims to be a simple and tolerant set of rules that puts the project into the safety zone
ً ً
4. Crystal methods are the most descriptive and least prescriptive ‫توجيها‬ ‫األكتيوصفيايواألقلي‬
‫ي‬
5. Focus on people and interactions and avoid rigid process definitions

 Cockburn findings on people’s behavior

1. People are communicating beings doing best face to face
2. People have trouble acting consistently over time‫ييواجهيالناسيصعوبةيفييالترصفيباستمرا يريمعيمرو يريالوقتي‬
3. People are highly variable from day to day and from place to place
4. People are generally good citizens, working to get the project to work‫المشوعي‬ ‫ييعملونيعىليتفعيلي ر‬

 The 7 properties of crystal clear

1. Frequent delivery: we must deliver our project each two month and about 2 deliveries per project
2. Reflective improvement: we need to work as a team to improve methodology and reflection
workshop
3. Osmotic communication: we need to sit close to share our knowledge to everyone on the team

4. Easy access to expert users: we must find real users to avoid mistakes when we design the features
and take feedback early
5. Personal safety: when you feel save you can take “critique” ‫نقد‬
6. Focus: there is a time for loud and quite
7. Agile technical environment: configuration management

 Crystal delivery vs. iteration

 Iteration: software is built to a point where it could be released
 Delivery: software is actually released to real users

 Focus 2-hour & 2-day rules(Properties) in Crystal

Rules should be set to keep focus and communication (Osmotic communication)
Two-hour rule: A known two-hour window during the day is defined where interruptions (communication)
not allowed
Two-day rule: If a developer is assigned work in a project, no switching to work in a second project before
two full days
 Extreme Programming XP
1. It has 12 practices must be followed to realize its benefits
2. The practices are clear and straight-forward but not flexible and not easy to apply
3. Requirements are expressed as scenarios (user stories)
4. Programmers work in pairs
5. Incremental development: small frequent releases

 XP Practices
1. Incremental planning: how we write stories and develop it to tasks and choose the priority.
2. Small releases: the special thing in XP it’s make a lot of releases
3. Simple design: make the current requirement and no more
4. Test-first development: make unit test first before write the code
5. Refactoring: from all developers are expected to refactor the code every time possible to keeps the
code simple and maintainable.
6. Pair programming: developers work in pairs.
7. Collective ownership: the pair of developers work on all area of code and it’s made responsibility for
all team and can change any thing
8. Continuous integration: every one shares the code and after complete the task it is integrated into
the whole system.
9. Sustainable pace ‫ وتتةيمستدامة‬: there is no overtime work.
10. on-site customer: one of xp team represent the customer and should be available full time.

 XP release cycle

select task‫ي‬ choose partner  write unit test  get latest code  refactor  integrate and run unit test
 run customer tests  release software  obtain user feedback  end project

 Refactoring
 Refactoring: Restructuring existing code without changing its functionality in any way
 Refactoring improves software structure, readability and Code quality, makes code easier to
maintain, and can lead to better performance, and avoids natural deterioration in structure when
software is changed
 You can refactor code with confidence if automated testing is used
 Lecture #7
 Unit testing
 Unit Testing: is a software testing technique in which individual units or components of a software
application are tested in isolation from the rest of the system.
 The purpose of unit testing is to verify that each unit of the software performs as we want and meets
the specified requirements.

 Project Without tests: has a head start but quickly slows down to point
hard to make any progress
 Project With tests: take some time at first because you will write test codes
for your functions or classes then write your functions but with that way
your progress will be much better because testing code will fix a lot of
problems as long as you are writing code and testing it always.
 Project with bad tests: exhibits the properties of a project with good tests
at the beginning, but it eventually falls into the stagnation phase ‫مرحلةيالركود‬

 Code coverage (Test coverage)

Ratio of number of code lines executed by at least one test and the total number of lines in
the production code base

‫معتيانيالنسبةيمنخفضةيانيفيسطوريفيالكوديلمييتمياختبارها‬
Low percentage code coverage means that maybe we need more test cases
but high percentage isn't good indication that we have tested everything
 Branch coverage
Ratio of number of code branches exercised by the test suite and the total number of
branches in the production code base

In code coverage we said that coverage is 100% because it is one line but actually this line
has two branches true and false so branch coverage is 50%

Branch coverage solved the code coverage problem but as shown

in this code external library function is used. We don’t know how
the code is written and how many branches we have so this is the
branch coverage problem

 Coverage metrics conclusion

1. Coverage metrics (code coverage and branch coverage) are a good negative indicator
but a bad positive one
2. Low coverage numbers are a certain sign of trouble
3. High coverage numbers does not guarantee that the test suite is of high quality
4. Measuring coverage metrics should only be a first step on the way to a quality test
suite