Revision on First 7 Chapters of

software_development_and_prof
essional_practice
 CHAPTER 1
INTRODUCTION TO SOFTWARE
DEVELOPMENT
 Software development is the process of taking a set of
requirements from a user (a problem statement), analyzing
them, designing a solution to the problem, and then
implementing that solution on a computer.
 Programming is really the implementation part, or possibly the
design and implementation part, of software development
 Programming is central to software development, but it is not
the whole thing.
 Software engineering also involves a process and includes
software development, but it also includes the entire
management side of creating a computer program that people
will use.
 Software engineering includes project management,
configuration management, scheduling and estimation,
baseline building and scheduling, managing people, and
several other things.
 Software development is the fun part of software engineering.
 software development is a narrowing of the focus of software
engineering to just that part concerned with the creation of the
actual software
 Broadening of the focus of programming to include analysis,
design and release issues.
 The fact that software development is only part of software
engineering, software development is the heart of every
software project.
 The Extreme Programming agile development methodology
requires that a customer be part of the development team and
be on site daily
 Software development is the heart of every software project,
and it is the heart of software engineering.
 “[Programming is] the only job I can think of where I get to be
both an engineer and an artist.

CHAPTER 2
PROCESS LIFE CYCLE MODELS
 Every program has a life cycle – all programs go through the
same steps:
1. Conception
2. Requirements gathering/exploration/modeling
3. Design
4. Coding and debugging
5. Testing
6. Release
7. Maintenance/software evolution
8. Retirement
 Every life cycle model, however, is a variation on two
fundamental types
 In the first type, the project team will generally do a
complete life cycle – at least steps 2 through 7– before
they go back and start on the next version of the product.
 In the second type, which is more prevalent these days,
the project team will generally do a partial life cycle –
usually steps 3 through 5 – and iterate through those
steps several times before proceeding to the release step.
 1) Traditional plan-driven models
 2) The newer agile development models.
 There is no one best process for developing software, and base
that decision on the project domain, the size of the project, the
experience of the team, and the timeline of the project.

 Code and Fix

 In this model, there are no formal requirements, no required
documentation, no quality assurance or formal testing, and
release is haphazard at best. Do not even think about effort
estimates or schedules when using this model.
 Take a minimal amount of time to understand the problem and
then start coding.
 There’s no maintenance involved and the model works well for
small, single-person programs
 A very dangerous model for any other kind of program.
 It’s useful to validate architectural decisions and to show a
quick version of a user interface design

 Waterfall
 The first and most traditional of the plan-driven process models
is the waterfall model.
 It requires detailed documentation at each stage, along with
reviews, archiving of the documents, sign-offs at each process
phase, configuration management, and close management of
the entire project
 There are two fundamental and related problems:
 First, it generally requires that you finish phase N before
you continue on to phase N+1.
 The second problem with the waterfall is that, as stated, it
has no provision for backing up, no way to go back and
rework your design if you find a problem during
implementation.
 The waterfall is a terrific theoretical model. It isolates the
different phases of the life cycle and forces you to think about
what you really do need to know before you move on.
 waterfall with feedback model
 You have to start work with incomplete requirements, design,
test plan, and so on. It also explicitly builds in the idea that you
will have to go back to previous process steps as new
information about your project is uncovered
 Same advantages of a waterfall model when it comes to very
large, new projects and inexperienced teams.
 The two main disadvantages:
 it really messes with your scheduling big time,
 it makes it harder to know when you’re finished
 The waterfall with feedback model also morphs into a new
model, one that attempts to address the scheduling and
uncertainty issues.
 The key to iterative development is in the software development
world, analyze some, design some, code some, and test some
every day.

 Evolutionary prototyping.
 Each version is refined using customer feedback and the
results of integration and system testing.
 This model evolved into the modern agile development
processes.
 That feedback is a critical element of good analysis and design.
It’s somewhat risky from a scheduling point of view
 It also provides good customer and end user input to product
requirements and does a good job of prioritizing those
requirements.
 On the downside, evolutionary prototyping leads to the danger
of unrealistic schedules, budget overruns, and overly optimistic
progress expectations.
 Conclusion of Evolutionary prototyping: works best with tight,
experienced teams who have worked on several projects
together. This type of cohesive team is productive and
 dexterous, able to focus on each iteration and usually
producing the coherent, extensible designs that a series of
prototypes requires. This model is not generally recommended
for inexperienced teams.

 Agile
 It required less documentation and fewer process controls. It
was targeted at small to medium-sized software projects and
smaller teams of developers.
 Quickly adjust to changing requirements and customer
demands, and it proposed to release completed software much
more quickly than the plan-driven models.
 Goal of any software development project is working code.
 Lightweight methodologies have several characteristics
 They tend to emphasize writing tests before code, frequent
product releases, significant customer involvement in
development, common code ownership, and refactoring –
rewriting code to make it simpler and easier to maintain
 Conclusion of lightweight methodologies: successfully used in
many small and medium-sized projects – say up to about 500K
lines of code. Lightweight methodologies also require process
discipline, especially in the beginning of a project when initial
requirements and an iteration cycle are created and in the test-
driven-development used as the heart of the coding process.

 eXtreme Programming (XP)

 XP is a “lightweight, efficient, low-risk, flexible, predictable,
scientific, and fun way to develop software.”
 XP four fundamental ideas:
 Heavy customer involvement
 Continuous unit testing (also known as test-driven
development [TDD])
 Pair programming
 Short iteration cycles and frequent releases
 XP Motivation
 Risk is the most basic problem in software
 Managing risk is a very difficult and time-consuming
management problem
 XP seeks to minimize risk by controlling the four variables of
software development.

 The Four Variables: => (‫ميدتيرم‬ ‫)سؤال‬

 Cost
 Time
 Features
 Quality
 Cost is probably the most constrained
 Time is your delivery schedule
 Quality is the number and severity of defects you are willing to
release with.
 Features (also called scope) is what the product actually does.

 The Four Values: =>(‫)مهم برده الزم نفرقه عن الى فوق‬

 Communication
 Simplicity
 Feedback
 Courage
 The 15 Principles:
 Rapid feedback
 Assume simplicity
 Incremental change
 Embracing change
 Quality work
  Teach learning
 Small initial investment
 Play to win
 Concrete experiments
 Open, honest communication
 Work with people’s instincts, not against them
 Accepted responsibility
 Local adaptation
 Travel light
 Honest measurement

 The Four Basic Activities:

 Coding
 Testing
 Listening
 Designing

 Scrum
 The idea in the agile Scrum methodology is that a small team is
unified around a single goal and gets together for sprints of
development that move them towards that goal.
 Scrum is a variation on the iterative development approach and
incorporates many of the features of XP
 Scrum is more of a management approach than XP and doesn’t
define many of the detailed development practices
 Scrum uses teams of no more than 10 developers
 Scrum is characterized by the sprint, between one and four
weeks
 A sprint always delivers a usable product
 two backlogs:
  The product backlog is the prioritized list of all the
requirements for the project
 The sprint backlog is the prioritized list of requirements
(say user stories) for the current sprint, Once the sprint
starts, only the development team may add items to the
sprint backlog
 Scrum projects have a daily scrum meeting, 15–30 minutes
 A Scrum retrospective is held before the next sprint begins to
ponder the previous sprint and see if there are any process
improvements that can be made
 Scrum is a project management methodology and is typically
silent on development processes.
 Scrum teams typically use many of the practices described
above in the XP practices
 Continuous integration and coding standards are all common
practices in Scrum projects.

CHAPTER 3
PROJECT MANAGEMENT
ESSENTIALS

 Project Planning
 Project planning continues throughout the entire duration of
the project.
 “The Plan” is never really set in stone,
 project plan is an actual document that is written by the project
manager, and that is approved and signed off on by the
development team and by upper management
 project plan consists of the following seven parts:
 Introduction and explanation of the project
  Project organization
 Risk analysis
 Hardware, software, and human resource requirements
 Work breakdown and task estimates
 Project schedule
 Project monitoring and reporting mechanisms,
collectively known as project oversight
 plan-driven projects will use all of them
 Agile projects may use a few on a single page.
 The problem with a project plan is that it is static.

 Project Organization
 How you’re going to organize the team
 What process model the project will be using
 How will the project be run on a day-to-day basis

 Risk Analysis
 Schedule slips
 Defect rate is excessive
 Requirements misunderstood
 Requirements churn
 Turnover
 what you’ll do if the worst-case scenario does happen; this is
mitigation
 iterative process model, it’s a good idea to revisit your risks
after every iteration

 Work Breakdown and Task Estimates

 The first step toward a project schedule is seeing what you will
be doing and how long each step will take.
 can’t really do estimation until you have a fairly detailed work
breakdown into tasks
 Once you have a believable list of tasks, you can start doing
size and then effort estimation
 Size always needs to come first, because you just can’t figure
out how long something will take until you have an idea of how
big it is
 The estimation mantra is size first, then effort and cost
estimates, then schedule.
 Managers should never do development estimates

 Project Schedule
 Get your developers to tell you the dependencies between
tasks
 Figure out what your duty cycle is
 Take weekends, vacations, sick days, training, and slack
into account when you’re making the schedule
 You cannot schedule a developer to work on two tasks at
the same time.
 Velocity is a term from XP5 and is defined as the estimated
effort of a task, divided by the actual effort

 Defects
 Most development organizations have a set of defect levels
they use to characterize just how bad a defect really is. One set
of levels looks like the following:
 Fatal
 Severe
 Serious
 Annoying
 New Feature Request

 The Post-Mortem
 Most development teams will do a post-mortem after every
project
 A post-mortem is an opportunity to reflect on the project just
completed and answer a few questions

CHAPTER 4
REQUIREMENTS
 That’s what requirements are: a list of stuff you have to
implement in order to create your terrific program
 Requirements tells you just what the program is supposed to
do. It gives you the scaffolding around which you’ll hang your
design
 Functional requirements: the list of features the user will see
and be able to use when they fire up your program.
 These are the “black box” requirements
 external behavior of your program
 lead to lower-level requirements that talk more about how your
program works, rather than what it does
 Output of this process of identifying requirements is a
functional specification of what the software system is
supposed to do.

 Functional Specification
 functional specification describes what the program will do
entirely from the user’s perspective
 doesn’t care how the software is implemented
 the features of the program and specifies screens, menus,
dialogs, and the like

 technical specification
 describes the internal implementation details of the program
 talks about data structures, algorithms used, database models,
choice of programming language
 agile methodologies do write functional specifications
 XP requires that together with the customer representative you
write user stories that lay out what the program will do, That’s a
spec

 That Natural Language Thing

 Functional specifications should always be written in a natural
language
 Outline of a Functional Specification
 Every functional specification is different
 Every function specification should have the elements
discussed in the following sections.
 Overview: this is your executive summary, at most two of
what the program is supposed to do.
 Disclaimer You should always put it a statement right at
the beginning
 Author’s Name Somebody needs to be responsible for the
functional specification, This is usually either the
development manager, the project manager, or the chief
architect
 project managers that are in charge of the specification, design,
and schedule
 The chief architect model is like the project manager model
except,
 The architect is a developer and so is more technically
competent and is usually in charge of the functional
specification and all the program design issues.
 great way to get customers to respond to your requirements list
is to present several scenarios of typical usage of the program
 This has a couple of advantages:
  If you write the scenarios as if they are user stories, the
customer is more likely to read them.
 customers are more likely to understand what you’re
doing
 agile methodologies, including XP, user stories are often
written like scenarios
 And in XP, the customer is part of the project team
 nothing beats natural language for describing usage scenarios

 Non-requirements
 most important section of the functional specification
 tells the world what you’re not going to do
 most important thing the functional specification does is
manage expectations
 Backlog: all the requirements you are going to consider for the
next release of the product
 functional specifications don’t have a “Backlog” section
 tells the customer you haven’t forgotten these features
 by moving them to the next release you are committed to
delivering the current release as close to the published
schedule as possible
 tells the developers that you’re not out of control and that the
project has a good shot at being done with high quality and on
time
 The only time a functional specification is complete is when
you ship the release

 Types of Requirements
 Four different types of requirements:
 user requirements,
 domain requirements,
 non-functional requirements,
  Non-requirements.

 User Requirements
 nearly always expressed in natural language
 the details of what the user expects to see as she uses the
program
 Any interaction element in the program should be described in
the user requirements

 Domain Requirements
 requirements that are imposed on you by the application
domain of the program
 Domain requirements are usually considered “middle layer”
software because they are the heart of the application
 below the user interface and above the operating system,
networking, or database software

 Non-functional Requirements
 constraints on the services and functions of the program and
also expectations about performance

 Non-requirements
 things you’re not going to do

 Requirements Digging
 “requirements elicitation” to talk about the process of getting
your users to tell you what they want
 “requirements digging” to emphasize the point that what you’re
really doing is digging for all those requirements that your
customer doesn’t know they want yet
 two ways to overcome problems of understanding:
 first is to have someone in the middle who has lived in
both worlds and who can translate between the two
 second way to promote understanding is to have the
customer as part of the development team
 Analyzing the Requirements
 Analysis has three basic parts:
 First, you categorize the requirements and organize them
into related areas. This will help the designers a lot.
 Second, you prioritize them based on customer input.
This is critical because you won’t be able to implement all
the requirements in the first product release
 Lastly, you need to examine each requirement in relation
to all the others to make sure they fit into a coherent
whole

CHAPTER 5
SOFTWARE ARCHITECTURE
 There are really two levels of software design
 detailed design
 style
 Software architecture: a set of ideas that tells you which
foundation is the right one for your program.
 Idea of software architecture began as a response to the
increasing size and complexity of programs.
 all programs of any size and complexity have an architecture
 larger programs need to be more intentional about your
thinking about the architecture
 It is so much harder to change things at the architectural level
once the program has been written, because architectural
features are so fundamental to the structure of the program.
 software architect starts thinking about an architecture for a
program, she usually starts by drawing pictures
 Software architectures normally represented as black box
graphs where graph nodes are computational structures and
 the graph edges are communication conduits between the
structures
 United Modeling Language (UML).
 Visual descriptions of architectures are generally easier to
understand
 particular architectural style is a pattern that can represent a
set of similar structures

 Pipe-and-filter Architecture
 the computational components are called filters
 they act as transducers that take input, transform it according
to one or more algorithms, and then output the result to a
communications conduit
 The input and outputs conduits are called pipes.
 The filters must be independent components
 You can join different filters in the set in different arrangements
in order to get different results

 An Object-Oriented Architectural Pattern

 The Model-View-Controller (MVC)
 a way of breaking an application, or even just a piece of an
application’s interface, into three parts:
 the model,
 the view,
 the controller

 Input ➤ Processing ➤ Output

 Controller ➤ Model ➤ View

 The controller interprets mouse and keyboard inputs from the
user and maps these user actions into commands that are sent
to the model and/or viewport
 The model manages one or more data elements, responds to
queries about its state, and responds to instructions to change
state; it models the problem you are trying to solve.
 view or viewport manages a rectangular area of the display and
is responsible for presenting data to the user through a
combination of graphics and text,
 Take instructions from the controller and data from the model
and displays them.
 It communicates back to the model and controller to report
status.
 user interface is displayed by the view but controlled by the
controller
 The model has no direct knowledge of the view
 The main idea here is separation of concerns – and code
 The objective is to separate how your program works from what
it is displaying and how it gets its input data
 The model represents the rules of the game. It does all the
computation
 The view displays what is going on
 The view is completely passive, what is happening inside the
model
 The controller is the part of the program that displays the
controls
 It knows as little as possible about the model and view; it tells
the model when to go and when to stop.
 The advantages: We can safely rewrite the GUI in the Controller
object or the display in the view object without changing the
model
 We can re-use the GUI for a different application with very little
effort

 The Client-Server Architectural Pattern

 In a client-server architecture, your program is broken up into
two different pieces that typically run on two separate
computers:
 A server, does most of the heavy lifting and computation;
it provides services to its clients across a high-bandwidth
network
 Clients, on the other hand, mostly just handle user input,
display output, and provide communication to the server
 In short, the client program sends requests for services to the
server program. The server program then evaluates the request,
does whatever computation is necessary (including accessing
a database, if needed) and responds to the client’s request with
an answer
 Clients and servers don’t have to be on different computers

 The Layered Approach

 suggests that programs can be structured as a series of layers
 like geologic strata, with a sequence of well-defined interfaces
between the layers
 one can change the internals of any layer without having to
change any of the other layers in the program
 Two classic examples: operating systems (OSs) and
communications protocols.
 operating system’s architecture has several objectives:
 centralize control of the limited hardware resources
 protect users from each other
 user applications request operating system services

 make requests through the kernel

 The Main Program: Subroutine Architectural Pattern

 traditional and oldest architectural pattern
 You start with a big problem, and then try to decompose the
problem into several smaller problems or pieces of the original
problem
 you look at each piece individually and continue dividing,
ignoring all the other pieces as you go
 solve the problem from the top down, and write the code from
the bottom up
 Conclusion: The software architecture is the core of your
application. The foundation on which you build the rest of the
program. It drives the rest of your design

CHAPTER 6
DESIGN PRINCIPLES
 One way to look at software problems is with a model that
divides the problems into two different layers:
• “Wicked” problems fall in the upper layer
These problems typically come from domains outside of
computer science
Tend to be open-ended, ill defined, and large in the sense that
they require much work
• “Tame” problems fall in the lower layer
These problems tend to cut across other problem domains
Tend to be better defined and small
 Sorting and searching are great examples of tame problems
 Tame problems clearly defined and you know when you have a
solution
 wicked problem is one for which the requirements are
completely known only after the problem is solved, or for which
the requirements and solution evolve over time
 A wicked problem is not understood until after the creation of a
solution, problem is defined and solved at the same time
 Wicked problems have no stopping rule
 Solutions to wicked problems are not right or wrong, but better
or worse, good-enough or not-good-enough
 Every wicked problem is essentially novel and unique
 Every solution to a wicked problem is a ‘one shot operation’
 Wicked problems have no given alternative solutions
 Expert systems require a user interface, an inference engine, a
set of rules, and a database of domain information
 real wicked problem solvers tend to use an approach that
swings from requirements analysis to solution modeling and
back until the problem solution is good enough
 opportunity-driven or opportunistic approach: the designers
are looking for any opportunity to make progress toward the
solution
 a list of characteristics of “tame” problems:
• has a well-defined and stable problem statement
• has a definite stopping point, i.e., when the solution is
reached
• has a solution, which can be objectively evaluated as right or
wrong
• belongs to a class of similar problems which are all solved in
the same similar way
• has solutions which can be easily tried and abandoned; and
• comes with a limited set of alternative solutions.”

 The Design Process

 Design is messy. Even if you completely understand the
problem requirements (it’s a tame problem)
 Design is about tradeoffs and priorities
 Design is heuristic
 Software design is done using a set of ever-changing heuristics
(rules of thumb) that each designer acquires over the course of
a career
 Designs evolve
 Desirable Design Characteristics
 Fitness of purpose. Your design must work, and work correctly
 Separation of concerns. Related closely to modularity
 Simplicity. Keep your design as simple as possible
 In agile methodologies, this idea of simplicity is kept in front of
you all the time
 Ease of maintenance. A simple, understandable design is
amenable to change
 Loose coupling. the degree to which the classes depend on
each other is called coupling
 High cohesion. The complement of loose coupling is high
cohesion
 Cohesion within a module is the degree to which the module is
self-contained with regards both to the data it holds and the
operations that act on the data
 Extensibility. An outgrowth of simplicity and coupling is the
ability to add new features to the design easily. This is
extensibility
 Portability. your software may need to be ported to another
platform

 Design Heuristics
 intellectual distance: how far your design is from a real world
object, The heuristic here is to try to find real world objects that
are close to things you want to model in your program
 Abstraction: put off what you need to do by pushing it higher in
the design hierarchy (more abstraction) or pushing it further
down (more details)
 Abstraction is a key element of managing the complexity of a
large problem
 A fundamental part of object-oriented design is encapsulation,
a concept that derives from information hiding
 Keep your design modular. Breaking your design up into semi-
independent pieces
 Identify the parts of your design that are likely to change
 Designers and Creativity
 process that seems to be what most of the designers followed:
1. Understand the problem.
2. Decompose the problem into goals and objects.
3. Select and compose plans to solve the problem.
4. Implement the plans.
5. Reflect on the design product and process.

6. Build a mental model of a proposed solution.

7. Mentally execute the model to see if it solves the problem –
make up input and simulate the model in your head.
8. If what you get is not correct, then change the model to
remove the errors and go back to step 2 to simulate again.
9. When your sample input produces the correct output, select
some more input values and go back and do steps 2 and 3
again.
10. When you have done this enough times (you’ll know
because you’re experienced) then you’ve got a good model and
you can stop
 Design is fundamentally a function of the mind, and is
idiosyncratic and depends on things about the designer that
are outside the process itself.

CHAPTER 7
STRUCTURED DESIGN
 Structured programming: one begins with the problem
statement and attempts to break the problem down into a set of
solvable sub-problems. The process continues until each sub-
problem is small enough to be either trivial or very easy to
solve.

 Stepwise refinement
 Stepwise refinement contends that designing programs
consists of a set of refinement steps. In each step, a given task
is broken up into a number of subtasks
 Each refinement of a task must be accompanied by a
refinement of the data description and the interface
 Each refinement implies a number of design decisions based
on a set of design criteria
 Refinement can proceed in two ways, top-down or bottom-up
 Top-down refinement: characterized by moving from a general
description of the problem to detailed statements of what
individual modules or routines do
 Bottom-up assessment: results in early identification of utility
routines, which can lead to a more compact design. It also
helps promote reuse – because you are reusing the lower level
routines.
 On the downside, bottom-up assessment is hard to use
exclusively
 Modular Decomposition
 one could design programs using a technique called modularity
 a decomposition based on information hiding, one of the key
techniques in object-oriented programming
 object-oriented analysis and design (OOA&D)
 separation of concerns: is the process of separating a
computer program into distinct features that overlap in
functionality as little as possible
 A concern: is any piece of interest or focus in a program
 concerns are synonymous with features or behaviors
 Progress towards separation of concerns is traditionally
achieved through modularity of programming and
encapsulation
 separation of concerns was all about separating functionality of
the program
 There are three characteristics of modularity that are key to
creating modular programs:
• Encapsulation
• Loose coupling (how closely do modules relate to each other)
• Information hiding
 In a nutshell, encapsulation means to bundle a group of
services defined by their data and behaviors together as a
module, and keep them together
 a module should do just one thing
 The module then presents an interface to the user
 An objective of encapsulating services and data is high
cohesion
 The complement of encapsulation is loose coupling
 Loose coupling describes how strongly two modules are
related to each other
 we want to minimize the dependence any one module has on
another
 The goal is to create modules with internal integrity (strong
cohesion) and small, few, direct, visible, and flexible
connections to other modules (loose coupling).
 Coupling falls into four broad categories that go from good to
awful:
• Simple data coupling: Where non-structured data is passed
via parameter lists. This is the best kind of coupling
• Structured data coupling: Where structured data is passed via
parameter lists
• Control coupling: Where data from module A is passed to
module B and the content of the data tells module B what to do
• Global-data coupling: Where the two modules make use of the
same global data.
 Information hiding is often confused with encapsulation
 Encapsulation describes a process of wrapping both data and
behaviors into a single entity – in our case, a module
 Information hiding, on the other hand, says that the data and
behaviors in a module should be controlled and visible only to
the operations that act on the data within the module, so it’s
invisible to other, external, modules
 Hiding information in this manner allows clients of a module to
use the module successfully
 Also allows developers to change the implementation of the
module without affecting how the client uses the module.
 Keyword in Context (KWIC)