DMIoT, School of Computing

Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter One

Introduction and Overview

to Software Engineering
 Introduction
• The use of computers is growing very rapidly.
• Probably you can say no discipline that does not use
computer systems now.
• With this increased use of computer, the need for software is
increasing.
• The complexity of these systems is also increasing.
• Software Engineering is the discipline to deal with this crisis
(complexity).
 What is Software?
❖Software is defined as:
• The collection of computer programs, procedures, rules, and
associated documentation and data such as requirements,
design models and user manuals. Or
• Software is a set of programs, which is designed to
perform a well-defined function.
• A collection of programs whose objective is to enhance the
capabilities of the hardware.
• The collection of computer programs, procedure rules and
associated documentation and data.(IEEE)
 Cont’d…
• Software products may be developed for a particular
customer or may be developed for a general market.
• Software products may be:
• Generic - developed to be sold to a range of different customers
e.g. PC software such as Excel or Word.
• Bespoke (custom) - developed for a single customer according to
their specification.
➢A program to solve a problem and a programming systems
product (software) to solve the same problem are two
entirely different things.
• Much more effort and resources are required for software.
 Program Vs. Software
Program Software
• Usually small in size • large
• Author himself is sole user • Large number of users
• Single developer • Team of developers
• Lacks proper user interface • Well-designed interface
• Lacks proper documentation • Well documented &user-manual
prepared
• Ad hoc development.
• Systematic development

Brooks rule of thumb: software costs approximately ten times as

much as a corresponding program.
 Software Characteristics
➢Software doesn’t wear out: Software is not susceptible to the
environmental maladies (dust, vibration, abuse, temperature) that cause
hardware to wear out.
➢Most software is custom built: Software components designed and
implemented so that it can be reused in many different programs.
• This will enable the software engineer to create application from
reusable parts.
➢ Software is intangible: Software is invisible till it is ready and runs
➢Maintenance is without spare part
➢Software is complex
 Types of Software
▪ System Software: they are written to serve other programs.
• Characterized by heavy interaction with computer hardware,
concurrent operation that requires scheduling, resource sharing,
sophisticated process management.
• For example, compiler, operating systems.
▪ Embedded software: Controls hardware
▪ Real-time Software- Programs that monitor/analyze/control real world
events as they occur.
▪ Business Software- Programs that access, analyze and process
business information.
▪ Personal Computer Software : Word processing, spreadsheets,
computer graphics, multimedia, entertainment,
 Cont’d…
▪ Engineering/Scientific Software : Computer-aided design, system
simulation, and other interactive applications have begun to take on
real-time and even system software characteristics.
▪ Artificial Intelligence software : Use non numerical algorithms to solve
complex problems that are not amenable to computation.
• Includes robotics, expert systems, artificial neural networks, game
playing.
▪ Internet Software: Programs that support internet accesses and
applications.
• For example, search engine, browser, e-commerce software,
authoring tools.
 Software Crisis
▪ During software development, many problems are raised and that set of
problems is known as the software crisis.
▪ What are the symptoms of the software crisis?
• Fail to meet user requirements
• over budget
• Difficult to alter, debug, and enhance
• frequently crash
• Often delivered late
• use resources non-optimally.
 Cont’d…
Factors contributing to Software Crisis
✓Poor communication between the customer and software developer.
✓Poor project management
✓Lack of adequate training in software engineering and project
management
✓Increasing skill shortage and manpower turnover
✓Low productivity improvements.
 What is Software Engineering ?
• The term software engineering is the product of two
words, software and engineering.
➢Software is a collection of integrated programs.
➢Engineering is the application of scientific and practical
knowledge to invent, design, build, maintain, and improve
systems, processes, etc.
❑According to IEEE's definition software engineering can be
defined as:
• the application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software, and
the study of these approaches; that is, the application of
engineering to software.
 Cont’d…
• Software Engineering is an engineering branch related to
the evolution of software product using well-defined
scientific principles, techniques, and procedures.
• Software engineering is an engineering discipline whose
focus is the cost-effective development of high-quality
software systems.
➢The result of software engineering is an effective and
reliable software product.
 Cont’d…
❑Software engineering is an engineering discipline that
provides knowledge, tools, and methods for:
• Defining software requirements
• Performing software design
• Software construction
• Software testing
• Software maintenance tasks
• Software project management
 Cont’d…
Software Engineering Vs Computer Science
✓computer science is concerned with theory
fundamentals
✓software engineering is concerned with the
practicalities of developing and delivering useful
software
• Computer science theories are currently insufficient to act as
a complete underpinning for software engineering, but it is a
foundation for practical aspects of software engineering.
• CS is as essential for SW engineers as physics is for
electrical or mechanical engineers.
 Cont’d…
Software Engineering Vs System Engineering
➢Software engineering is part of System engineering.
➢System engineering is concerned with all aspects of
computer-based systems development including:
• Hardware,
• Software and
• Process engineering
• System engineers are involved in system specification,
architectural design, integration and deployment
 Software Quality
• Software quality product is defined in term of its fitness of purpose.
• That is, a quality product does precisely what the users want it to
do.
• For software products, the fitness of use is generally explained in terms
of satisfaction of the requirements laid down in the SRS document.
• Although "fitness of purpose" is a satisfactory interpretation of quality
for many devices such as a car, a table fan, etc. for software products,
"fitness of purpose" is not a wholly satisfactory definition of quality.
Example:
• Consider a functionally correct software product.
• That is, it performs all tasks as specified in the SRS document.
• But, has an almost unusable user interface.
➢Even though it may be functionally right, we cannot consider it to
be a quality product.
 Cont’d…
What is Good Software?
• Software has number of attributes which decide whether it is a good or bad .
• The software is required by the customer, used by the end users of an
organization and developed by software engineer .
• Each one will evaluate the different attributes differently in order to decide
whether the software is good.
• The three dimensions of quality of a software product:
➢Product operation: will be operation characteristics
• Correctness, Reliability, Efficiency, Integrity, usability
➢Product transition: adaptableness to new condition
• Portability, Reusability, Interoperability
➢Product revision: capability to undergo changes
• Maintainability, Flexibility, Testability
 Cont’d…
Software Sub Factors Definitions
Quality
Factors
Suitability The capability of software product to provides sets of
appropriate functions for specific user’s requirements.
Accuracy The capability of a software to deliver accurate results
Functionality

Security The capability of software to control unauthorized

access
Maturity The capability of the software product to avoid failure
due to errors in the software
Fault tolerance The capability of the software to maintain a certain
level of performance during either faults in the
Reliability
software or infringement of its interface.
Recoverability The capability of the software product to reestablish to
a certain level of performance and recover data
affected during failure
 Cont’d…
Software Sub Factors Definitions
Quality
Factors
Learnability The capability of the software product to enable the user
to learn its application
Training Indicates the effort required to teach how to use the
software to the users of software
Usability Communicati It associated to how well the software communicates to
veness the users.
Usability The capability of software product to adhere to guides,
compliance regulations and standards related to usability
Execution indicates the time a software takes to perform tasks
efficiency
Compliance
Storage The capacity of the software to use appropriate type and
efficiency amount of resources when performing its functions
 Cont’d…
Software Sub Factors Definitions
Quality
Factors
Communication The software that provide the use of
Commonality standard protocols.
Interoperability
Data Commonality The software that provide the use of
standard data representation.
Ease of Use, User Error It indicates the capacity of the software
Protection, Technical to be easily operated by end users
Operability Accessibility, Technical
Learnability
Consistent Text Layout, The user interface of the software
Aesthetic Page Layout, Font Size, product should be attractive, enjoyable
Font Color and pleasant enough for users to create
an emotional appeal to use it.
 Software Engineering and the
Engineering Profession
Profession
• A duty requiring specialized knowledge and often long and intensive
academic preparation
• Any working field or business
• A paid occupation, especially one that involves prolonged training and
a formal qualification.
Engineer
• The term “engineer” was first used in the sense of a military engineer
building of engines of war and other military construction.
• In the eighteenth century that the term “civil engineer” began to be
used to distinguish engineers who were concerned with civil rather
than military construction
 Cont’d…
History of Software Engineering
• Software is everywhere – buying bread, driving car, washing clothes
➢Software separated from the hardware in 1950’s – emerged as a distinct
technology – became independent product
• Original programmers recruited from the ranks of hardware engineers
and mathematicians.
 Cont’d…
Software Organization Structure
• A software house is a company whose primary products are software.
• Large and well-known companies producing Commercial off-the
shelf (COTS) such as Microsoft, Oracle Corporation, HP, Adobe
Systems, Apple Inc. etc.
• Companies producing Software as a Service SaaS, such as Google,
Facebook, LinkedIn
• Companies producing software components, such as Developer
Express, Dundas, Component One and Sohn Software
• Companies focused on delivering bespoke (custom-built) software
solutions for vertical industries or particular geographical regions
 Cont’d…
Common roles in a software house:
❑Professional software house normally consists of at least
three dedicated sub-teams:
• Business analysts who define the business needs of the
market.
• Software developers who create the technical
specification and write the software.
• Software testers who are responsible for the whole
process of quality management.
 Cont’d…
❑In bigger software houses, greater specialization is employed, and
quite often there are also:
• Technical writers who write all the documentation such as user
guides.
• Release specialists who are responsible for building the whole
product and software versioning.
• Graphic designers who are normally responsible for the design of
the graphical user interface.
• Maintenance Engineers who are behind two, three or more lines
of support.
• Consultants responsible for making the intelligence software,
integrating with existing solutions, and implementing business
scenarios in Business Process Management software.
 Ethics in Software Engineering
• Software engineering is carried out within a legal and social
framework that limits the freedom of engineers.
• Software engineers must accept that their job involves wider
responsibilities than simply the application of technical skills.
➢They must also behave in an ethical and morally responsible way
if they are to be respected as professionals.
• You should not use your skills and abilities to behave in a
dishonest way or in a way that will bring disrepute to the software
engineering profession.
 Cont’d…
• However, there are areas where standards of acceptable behaviour are
not bounded by laws but by the more tenuous notion of professional
responsibility.
• Some of these are:
1. Confidentiality
• You should normally respect the confidentiality of your employers or
clients irrespective of whether a formal confidentiality agreement has
been signed.
2. Competence
• You should not misrepresent your level of competence.
• You should not knowingly accept work that is outside your
competence.
 Cont’d…
3. Intellectual property rights
• You should be aware of local laws governing the use of intellectual
property such as patents and copyright.
• You should be careful to ensure that the intellectual property of
employers and clients is protected.
4. Computer misuse
• You should not use your technical skills to misuse other people’s
computers.
• Computer misuse ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious (dissemination of
viruses).
 Cont’d…
❑Professional societies and institutions have an important role to play in
setting ethical standards.
• Organizations such as the ACM, the IEEE and the British Computer
Society publish a code of professional conduct or code of ethics.
• Members of these organizations undertake to follow that code when
they sign up for membership.
• These codes of conduct are generally concerned with fundamental
ethical behaviour.
 Cont’d…
• The ACM and the IEEE have cooperated to produce a joint code of
ethics and professional practice.
• Computers have a central and growing role in commerce, industry,
government, medicine, education, entertainment and society at large.
• Software engineers are those who contribute by direct participation or
by teaching, to the analysis, specification, design, development,
certification, maintenance and testing of software systems.
• Because of their roles in developing software systems, software
engineers have significant opportunities to do good or cause harm, to
enable others to do good or cause harm, or to influence others to do
good or cause harm.
• To ensure, as much as possible, that their efforts will be used for good,
software engineers must commit themselves to making software
engineering a beneficial and respected profession.
 Cont’d…
❑In accordance with that commitment, software engineers shall adhere
to the following Code of Ethics and Professional Practice.
• The Code contains eight Principles related to the behaviour of and
decisions made by professional software engineers, including
practitioners, educators, managers, supervisors and policy makers, as
well as trainees and students of the profession.
• The principles identify the ethically responsible relationships in which
individuals, groups, and organizations participate and the primary
obligations within these relationships.
 Cont’d…
• The Clauses of each Principle are illustrations of some of the
obligations included in these relationships.
• These obligations are founded in the software engineer’s humanity, in
special care owed to people affected by the work of software engineers,
and the unique elements of the practice of software engineering.
• The Code prescribes these as obligations of anyone claiming to be or
aspiring to be a software engineer.
 Software Engineering Code of Ethics and
Professional Practice
ACM/IEEE-CS Joint Task Force on Software Engineering
Ethics and Professional Practices
• 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:
 Cont’d…
1. PUBLIC – Software engineers shall act consistently with the public
interest.
2. CLIENT AND EMPLOYER – Software engineers shall act in a
manner that is in the best interests of their client and employer
consistent with the public interest.
3. PRODUCT – Software engineers shall ensure that their products and
related modifications meet the highest professional standards
possible.
4. JUDGMENT – Software engineers shall maintain integrity and
independence in their professional judgment.
5. MANAGEMENT – Software engineering managers and leaders
shall subscribe to and promote an ethical approach to the
management of software development and maintenance.
6. PROFESSION – Software engineers shall advance the integrity and
reputation of the profession consistent with the public interest.
 Cont’d…
7. COLLEAGUES – Software engineers shall be fair to and supportive
of their colleagues.
8. 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.
Thank You!
?
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Two
Software Processes and Models
 Introduction
What is a process?
• A process is an organized set of activities, which transforms inputs to
outputs.
➢ We can use synonyms of process such as: procedure, method, course
of action, etc.
• Software engineering as a discipline has many processes.
➢ In the context of software engineering, a process is an adaptable
approach that enables the people doing the work (the software team)
to pick and choose the appropriate set of work actions and tasks.
• The intent is always to deliver software in a timely manner and with
sufficient quality to satisfy those who have sponsored its creation and
those who will use it.
 Software process
➢ What is it?

• When you work to build a product or system, it’s important to go

through a series of predictable steps—a road map that helps you create
a timely, high-quality result.
• The road map that you follow is called a “software process.”

➢ Who does it?

➢ Software engineers and their managers adapt the process to their

needs and then follow it.

➢ In addition, the people who have requested the software have a role to
play in the process of defining, building, and testing it.
 Cont’d…
➢ Why is it important?
• Because it provides stability, control, and organization to an activity
that can, if left uncontrolled, become quite chaotic.

➢ What are the steps?

• At a detailed level, the process that you adopt depends on the software
that you’re building.

➢ What is the work product?

• From the point of view of a software engineer, the work products are
the programs, documents, and data that are produced as a consequence
of the activities and tasks defined by the process.
 Cont’d…
➢ How do you ensure that you have done it right?
• There are a number of software process assessment mechanisms that
enable organizations to determine the “maturity” of their software
process.
• However, the quality, timeliness, and long-term viability of the
product you build are the best indicators of the efficacy of the process
that you use.
 Cont’d…
❑ Software process: organizing a structured set of activities
to develop software systems.
• These processes help in performing different software
engineering activities in an organized manner.
 Characteristics of processes
• Produces intermediate and final products.
• Each process activity has entry and exit criteria
• Activities are organized in sequence, so timing is clear.
• Each process has guiding principles including goals of each
activity.
• Uses resources, subject to set of constraints (such as
schedule, no. of people working )
• May be composed of sub-processes with hierarchy or links
 Cont’d…
❑There are many different software processes but all must
include four activities.
I. Software specification: the functionality of the software
and constraints on its operation must be defined.
II. Software design and implementation: the software to
meet the specification must be produced.
III.Software validation: the software must be validated to
ensure that it does what the customer wants.
IV.Software evolution: the software must evolve to meet
changing customer needs.
Sequential Software Process models
• Sequential models such as Waterfall or V-Model rely on
intensive periods of collecting and refining requirements for
a product before design and development activity can take
place.
• Products developed using these models are intended to be
complete when released to customers.
• Central to the approach is an assumption that by adhering to
the requirements captured at the beginning, the product will
fulfil the wishes of those customers.
 Cont’d…

Source: www.richrtesting.com (Richard Rogers)

 Iterative Software Process Models
• Emphasis on delivering less complex products, often to test
customer response before making adjustments.
• The techniques encourage regular feedback from customers,
and rapid response to that feedback;
• refining ideas and revisiting design and development
activities with the intention of delivering products which
better reflect what customers want.
 Cont’d…

Source: www.richrtesting.com (Richard Rogers)

 Software Development Life Cycle (SDLC)
• A Software Development Life Cycle (SDLC) is a well-defined,
structured sequence of stages in software engineering to develop the
intended software product.
• It is a process used by the software industry to design, develop and
test a high quality software.
➢ It aims to produce a high quality software that meets or exceeds
customer expectations, reaches completion with in times and cost
estimates.
• It is also called Software Development Process.
 Cont’d…
• The software development lifecycle begins with the identification of a
requirement for software and ends with the formal verification of the
developed software against that requirement.
• So SDLC goes through a series of phases.
• Helps to understand the entire process
• Enables planning of resources in advance
• Enforces a structured approach to development
• Helps to track progress of the system
 Cont’d…
❖ The software development life-cycle can be divided into 5-9 phases:
• Project initiation and planning
• Project identification and selection
• Feasibility study
• Project analysis
• System design
• Coding
• Testing
• Implementation
• Maintenance
 Cont’d…
I. Problem definition
• It is the decision about problems in the existing system and the motivation
for system change.
• The need for changes in the existing system are identified and shortcomings
of the existing system are detected.➔ which leads to Feasibility Study.
II. Feasibility Study is an analysis of the viability of an idea.
• Answer the essential question of “should we proceed with the proposed
project idea?”
• Used to identify how, where, and to whom you intend to sell a service or
product.
• Provides detail concept about your business.
• How and where the business is operate
• How can I succeed
 Cont’d…
➢ Organizational Feasibility: is how well a proposed information system
supports the objectives of the organization and is a strategic plan for an
information system.

➢ Economic feasibility (Cost/Benefits Analysis): how much start-up capital

is needed, sources of capital, returns on investment( profit ), etc.

• if a project can’t cover its development costs, it won’t be approved,

➢ Technical Feasibility

➢ Operational Feasibility

➢ Schedule Feasibility

➢ Political Feasibility
 Cont’d…
III. Project Analysis: a detailed study of the various operations
performed by a system and their relationships within and outside the
system.
• Examine and document the relevant aspects of the existing system,
its shortcomings and problems.
• Analyze the findings and record the results.
• Define and document the proposed system.
• Test the proposed design against the known facts.
• Produce a detailed report to support the proposals.
• Estimate the resources required to design and implement the
system.
 Cont’d…
• The objective is to provide solutions to stated problems, usually in
the form of specifications to meet the users requirements and to make
recommendations for a new computer-based system.
•Analysis is iterative and progressive process.
IV. System Design: it is the most creative and challenging phase.
▪ Determining data required to produce the output
▪ Determining processing methods and using software
▪ Determining methods of data capture
▪ Defining detailed critical procedures
▪ Calculating timings of processing
 Cont’d…
V. Coding: the goal of the coding phase is to translate the
design of the system into code in a given programming
language.
• affects both testing and maintenance
VI.Testing: testing is the major quality-control measure used
during software development.
• Its basic function is to detect errors in the software
VII.Implementation: it is mainly concerned with user
training, site selection, and preparation and file conversion.
 Cont’d…
VIII.Maintenance: it is an important part of the SDLC.
▪ But it has some problems:
• Availability of a few maintenance tools.
• User may not accept the cost of maintenance.
• Standards and guidelines of project may be poorly
defined.
• A good test plan is lacking.
 Classifications of SDLC Model
▪ There are a number of different models for software development
lifecycles which describe the interrelationships between software
development phases.
✓ Waterfall model
✓ prototype model
✓ incremental model
✓ V-shaped model
✓ Spiral model
 Waterfall model
❑ Organize the activities in linear fashion.
• Each phase is end up with expected output in the forms of document.
• Waterfall model is the simplest model.
• 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.
Classical Waterfall Model
 Cont’d…
▪ Classical waterfall model is idealistic:
• Assumes that no defect is introduced during any
development activity.
• In practice developers commit errors:
• Defects do get introduced in almost every phase of
the life cycle.
Iterative Waterfall Model
 Cont’d…
▪ Defects usually get detected much later in the life cycle:
• For example, a design defect might go unnoticed till the coding or
testing phase.
▪ Once a defect is detected:
• The phase in which it occurred and parts of the work already
completed subsequent phases needs to be reworked.
▪ Therefore need feedback paths in the classical waterfall model.
 Cont’d…
Waterfall model Strengths
• Easy to understand, easy to use
• Provides a reference to inexperienced staff
• Provides requirements stability
• Facilitates strong management control (plan, staff, track)

Waterfall Deficiencies
• All requirements must be known upfront
• Does not accommodate any change.
• There is no risk analysis.
• Can give a false impression of progress.
• Little opportunity for customer to pre-view the system.
 Cont’d…
When to use the Waterfall Model
• Requirements are very well known and stable
• Technology is understood
• Experienced Development team
• When it is possible to produce a stable design
E.g. a new version of an existing product
• E.g. porting an existing product to a new platform.
 Prototype process model
• It is model implementation of the project with limited
functionalities.
• The prototype model suggests that before development of
the actual software, a working prototype of the system
should be built first.
What is a Prototype?
• It is a quickly developed, easily modifiable and extendible
working model of the required application.
 Cont’d…
Reasons for prototyping
• learning by doing: useful where requirements are only partially known

• improved communication

• improved user involvement

• reduces the need for documentation

• reduces maintenance costs i.e. changes after the application goes live
Cont’d…
 Cont’d…
Prototyping: advantages
• The resulting software is more usable
• User needs are better accommodated
• The design is of higher quality
• The resulting software is easier to maintain
• Overall, the development incurs less effort

Prototyping Weaknesses
• Sometimes expensive
• Overall maintainability may be overlooked
• Process may continue forever (scope creep)
 Cont’d…
What is the main goal of prototyping model?
• To avoid early freezing of the requirements.

• Instead of freezing the requirement, prototype is built to

understand the requirement.

• To enable the client to better understand the requirement.

 Cont’d…
When to use the Prototyping Model?
• When requirements are not known at the beginning of the
project.
• When requirements are unstable and constantly changing.
• When quick demonstrations are required.
• When user requires proof of concept.
 Incremental process model
• Incremental development is dividing the project in various
independent parts and developing these sub-parts at the
same rate/ different rate and integrating them when ready.
➢ Steps
• Develop a system in smaller portions at a time.
• Then slowly add increased functionality.
• Each subsequent release of the system adds function to the
previous release, until all designed functionality has been
implemented.
Cont’d…
 Cont’d…

Incremental Model Strengths

• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
 Cont’d…
Incremental Model Weaknesses
 Requires good planning and design
 Requires early definition of a complete and fully functional system to
allow for the definition of increments
 Well-defined module interfaces are required
 Total cost of the complete system is not lower
 Cont’d…
When to use the Incremental Model
 Most of the requirements are known up-front but are expected to
evolve over time

 A need to get basic functionality to the market early

 On projects which have lengthy development schedules

 Spiral Model
• The spiral model is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model.
• It implements the potential for rapid development of new versions of
the software.
• Using the spiral model, the software is developed in a series of
incremental releases.
• During the early iterations, the additional release may be a paper
model or prototype.
• During later iterations, more and more complete versions of the
engineered system are produced.
Cont’d…
 Cont’d…
❑Each cycle in the spiral is divided into four parts:
✓ Objective setting: Each cycle in the spiral starts with the
identification of purpose for that cycle, the various alternatives that
are possible for achieving the targets, and the constraints that exists.
✓ Risk Assessment and reduction: The next phase in the cycle is to
calculate these various alternatives based on the goals and constraints.
• The focus of evaluation in this stage is located on the risk perception
for the project.
 Cont’d…
✓ Development and validation: The next phase is to develop strategies
that resolve uncertainties and risks.
• This process may include activities such as benchmarking, simulation,
and prototyping.
✓ Planning: Finally, the next step is planned.
• The project is reviewed, and a choice made whether to continue with a
further period of the spiral.
• If it is determined to keep, plans are drawn up for the next step of the
project.
 Cont’d…
❑ The development phase depends on the remaining risks.

• For example, if performance or user-interface risks are treated more essential

than the program development risks, the next phase may be an evolutionary
development that includes developing a more detailed prototype for solving
the risks.
❑ The risk-driven feature of the spiral model allows it to accommodate any
mixture of a specification-oriented, prototype-oriented, simulation-oriented,
or another type of approach.
• An essential element of the model is that each period of the spiral is
completed by a review that includes all the products developed during that
cycle, including plans for the next cycle.
• The spiral model works for development as well as enhancement projects.
 Cont’d…
Spiral Model Strengths
• Provides early indication of insurmountable risks, without much cost

• Users see the system early because of rapid prototyping tools

• Critical high-risk functions are developed first

• The design does not have to be perfect

• Users can be closely tied to all lifecycle steps

• Early and frequent feedback from users

• Cumulative costs assessed frequently

 Cont’d…
Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-risk
projects
• Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration
 Cont’d…
When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Users are unsure of their needs
• Requirements are complex
• When changes may require at any time
• Large and high budget projects
• When deliverance is required to be frequent.
 V Model
• It is a variant of the Waterfall
• emphasizes verification and validation
• V&V activities are spread over the entire life cycle.
• Verification and validation (V & V) is intended to show that a
system conforms to its specification and meets the requirements of the
system customer.
• In every phase of development:
• Testing activities are planned in parallel with development.
 Cont’d…
Developers life cycle Testers life cycle
 Cont’d…
Verification:
• It involves a static analysis method (review) done without executing code.
• It is the process of evaluation of the product development process to find
whether specified requirements meet.
Validation:
• It involves dynamic analysis method (functional, non-functional), testing is
done by executing code.
• Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer
expectations and requirements.
• Verification and Validation process is joined by coding phase in V-shape.
• Thus it is known as V-Model.
52
 Cont’d…
V-Shaped Steps
• Project and Requirements Planning – allocate resources
• Product Requirements and Specification Analysis – complete
specification of the software system
• Architecture or High-Level Design – defines how software functions
fulfill the design
• Detailed Design – develop algorithms for each architectural component
• Coding – transform algorithms into software
• Unit testing – check that each module acts as expected
• Integration and Testing – check that modules interconnect correctly
• System and acceptance testing – check the entire software system in its
environment
• Production, operation and maintenance – provide for enhancement and
corrections
 Cont’d…
V model Strengths
• Emphasize planning for verification and validation of the product in
early stages of product development.
• Each deliverable must be testable
• Easy to use

V Model Weaknesses
• Does not support overlapping of phases

• Does not handle iterations or phases

• Does not easily handle later changes in requirements

• Does not support risk analysis activities

 Cont’d…
When to use V Model
• All requirements are known up-front
• Solution and technology are known
• Natural choice for systems requiring high reliability:

• Embedded control applications

 Cont’d…
Reading assignment:
✓ RAD model
✓ Agile model
✓ Big bang model
Thank You!
?
57
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Three

Agile Development
 Introduction
What is it?
• Agile software engineering combines a philosophy and a set of
development guidelines.

➢The philosophy encourages:

• customer satisfaction and early incremental delivery of software;
• small, highly motivated project teams;
• informal methods;
• minimal software engineering work products; and
• overall development simplicity.

➢The development guidelines stress delivery over analysis and

design (although these activities are not discouraged), and active and
continuous communication between developers and customers.
 Cont’d…
Who does it?
• Software engineers and other project stakeholders (managers,
customers, end users) work together on an agile team (a team that is
self-organizing and in control of its own destiny).

• An agile team fosters communication and collaboration among all who

serve on it.

Why is it important?
➢Agile software engineering represents a reasonable alternative to
conventional software engineering for certain classes of software and
certain types of software projects.

• It has been demonstrated to deliver successful systems quickly.

 Cont’d…
What are the steps?
• The basic framework activities: communication, planning, modeling,
construction, and deployment remain.
➢But they morph into a minimal taskset that pushes the project team
toward construction and delivery (some would argue that this is done at
the expense of problem analysis and solution design).
What is the work product?
• Both the customer and the software engineer have the same view the
only really important work product is an operational “software
increment” that is delivered to the customer on the appropriate
commitment date.
How do you ensure that you have done it right?
• If the agile team agrees that the process works, and the team produces
deliverable software increments that satisfy the customer, you’ve done
it right.
 Cont’d…
❑In the modern economy, it is often difficult or impossible to predict
how a computer-based system (e.g., a Web-based application) will
evolve as time passes.
• Market conditions change rapidly, end-user needs evolve, and new
competitive threats emerge without warning.
• In many situations, you won’t be able to define requirements fully
before the project begins.
❖You must be agile enough to respond to a fluid business environment.
• Fluidity implies change, and change is expensive, particularly if it
is uncontrolled or poorly managed.
• One of the most compelling characteristics of the agile approach is its
ability to reduce the costs of change throughout the software process.
 What is Agility?
Agility in context of software engineering:
➢Agility means effective (rapid and adaptive) response to change,
effective communication among all stockholders.
▪ The agile process forces the development team to focus on software
itself rather than design and documentation.
▪ The agile process believes in iterative method.
▪ The aim of agile process is to deliver the working model of software
quickly to the customer.
▪ For example: Extreme programming is the best known of agile
process.
 Cont’d…
❑Agility can be applied to any software process.
• However, to accomplish this, it is essential that the process be designed
in a way that allows the project team to:
✓ adapt tasks and to streamline them,
✓conduct planning in a way that understands the fluidity of an agile
development approach and
✓emphasize an incremental delivery strategy that gets working
software to the customer as rapidly as feasible.
 Agility and the Cost of Change
❑The cost of change increases nonlinearly as a project progresses.
• It is relatively easy to accommodate a change when a software team is
gathering requirements (early in a project).
• The costs of doing this work are minimal, and the time required will
not adversely affect the outcome of the project.
❑But what if we fast-forward a number of months? The team is in the
middle of validation testing (something that occurs relatively late in
the project), and an important stakeholder is requesting a major
functional change.
➢The change requires a modification to the architectural design of
the software, the design and construction of new components,
modifications to another components, the design of new tests, and
so on.
 Cont’d…
•1

Cost of change using

conventional software
processes

Cost of change using

agile processes

Idealized cost of change

using agile process

Development schedule progress

Figure 3.1 Change costs
 Cont’d…
• A well-designed agile process “flattens” the cost of change curve
(Figure 3.1, shaded, solid curve), allowing a software team to
accommodate changes late in a software project without dramatic cost
and time impact.
• When incremental delivery is coupled with other agile practices such
as continuous unit testing and pair programming, the cost of making a
change is attenuated (reduced).
 What is an Agile Process?
• Any agile software process is characterized in a manner that addresses
a number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will
persist and which will change.
• It is equally difficult to predict how customer priorities will change
as the project proceeds.
2. For many types of software, design and construction are interleaved.
• That is, both activities should be performed in tandem so that
design models are proven as they are created.
• It is difficult to predict how much design is necessary before
construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from
a planning point of view) as we might like.
 Cont’d…
• An agile software process must adapt incrementally.
• To accomplish incremental adaptation, an agile team requires customer
feedback (so that the appropriate adaptations can be made).
• An effective catalyst for customer feedback is an operational prototype
or a portion of an operational system.
• Hence, an incremental development strategy should be instituted.
➢Software increments (executable prototypes or portions of an
operational system) must be delivered in short time periods so that
adaptation keeps pace with change (unpredictability).
• This iterative approach enables the customer to evaluate the software
increment regularly, provide necessary feedback to the software team,
and influence the process adaptations that are made to accommodate
the feedback.
 Principles of Agility
1. The highest aim is to satisfy customers by delivering useful software
on time and on a consistent basis.
2. Changes in regulations should be welcomed. Even late in the
development process, tolerating change is seen as gaining a
competitive edge for the client.
3. Frequently delivering functioning software, with a bias towards
shorter delivery times (e.g., every 2 or 3 weeks)
4. During the project, business people and developers must collaborate
on a daily basis.
5. Build initiatives around motivated people, provide them with the
atmosphere and support they need, and trust them to complete the
task.
6. Within the development team, face-to-face contact is the most
efficient technique of transmitting knowledge.
 Cont’d…
7. Working software is the most important indicator of progress.
8. Agile approaches encourage long-term development, therefore
developers and clients should be able to keep working on projects
forever.
9. A constant focus on technical excellence and smart design improve
agility.
10. Simplicity (defined as maximizing the amount of labor that isn't
done) is critical.
11. Self-organizing teams provide the finest architectures, requirements,
and designs.
12. Teams think about how to become more successful at regular
intervals and alter their behavior appropriately.
➢Not every agile process model applies these 12 principles with equal
weight, and some models choose to ignore (or at least downplay) the
importance of one or more of the principles.
 Factors Affecting Humans
• Members of agile development teams must possess the following
characteristics.
✓Competence
✓a common goal
✓Collaboration
✓Ability to make decisions
✓Ability to solve ambiguous problems
✓Mutual respect and trust
✓Self-organization
 Extreme Programming (XP)
• It is the most widely used approach(model) to agile software
development.
• Although early work on the ideas and methods associated with XP
occurred during the late 1980s, the seminal work on the subject has
been written by Kent Beck.
• More recently, a variant of XP, called Industrial XP (IXP) has been
proposed.
• IXP refines XP and targets the agile process specifically for use within
large organizations
 XP Values
• Beck defines a set of five values that establish a foundation for all work
performed as part of XP: communication, simplicity, feedback, courage,
and respect.
• Each of these values is used as a driver for specific XP activities, actions, and
tasks.
1. In order to achieve effective communication between software engineers
and other stakeholders (e.g., to establish required features and functions for
the software), XP emphasizes:
✓ close, yet informal (verbal) collaboration between customers and
developers,
✓the establishment of effective metaphors for communicating important
concepts,
✓continuous feedback, and
✓the avoidance of voluminous documentation
as a communication medium.
 Cont’d…
2. To achieve simplicity, XP restricts developers to design only for
immediate needs, rather than consider future needs.
• The intent is to create a simple design that can be easily implemented
in code).
• If the design must be improved, it can be refactored at a later time.
3. Feedback is derived from three sources:
• the implemented software itself,
• the customer, and
• other software team members.
• By designing and implementing an effective testing strategy, the
software (via test results) provides the agile team with feedback.
 Cont’d…
• XP makes use of the unit test as its primary testing tactic.
• As each class is developed, the team develops a unit test to exercise
each operation according to its specified functionality.
➢As an increment is delivered to a customer, the user stories or use
cases that are implemented by the increment are used as a basis for
acceptance tests.
➢The degree to which the software implements the output, function, and
behavior of the use case is a form of feedback.
• Finally, as new requirements are derived as part of iterative planning,
the team provides the customer with rapid feedback regarding cost and
schedule impact.
 Cont’d…
4. Beck argues that strict adherence to certain XP practices demands
courage.
• An agile XP team must have the discipline (courage) to design for
today, recognizing that future requirements may change dramatically,
thereby demanding substantial rework of the design and implemented
code.
5. By following each of these values, the agile team inculcates respect
among it members, between other stakeholders and team members,
and indirectly, for the software itself.
• As they achieve successful delivery of software increments, the team
develops growing respect for the XP process.
 The XP Process
• Extreme Programming uses an object-oriented approach as its preferred
development paradigm.
• XP encompasses a set of rules and practices that occur within the context of four
framework activities: planning, design, coding, and testing.

Figure 3.2 The Extreme Programming process

 Cont’d…
1. Planning
• The planning activity begins with the creation of a set of stories that
describe required features and functionality for software to be built.
• Each story is written by the customer and is placed on an index card.
• The customer assigns a value to the story based on the overall business value of
the feature of function.
• Members of the XP (Extreme Programming) team then assess each
story and assign a cost measured in development weeks to it.
• If the story will require more than three development weeks, the
customer is asked to split the story into smaller stories, and the
assignment of value and cost occurs again.
• Customers and the XP team work together to decide how to group
stories into the next release to be developed by the XP team.
 Cont’d…
• Once a basic commitment is made for a release, the XP team orders
the stories that will be developed in one of three ways:
1. All stories will be implemented immediately.
2. The stories with highest value will be moved up in the schedule
and implemented first.
3. The riskiest stories will be moved up in the schedule and
implemented first.
• As development work proceeds, the customer can add stories, change
the value of an existing story, split stories or eliminate them.
• The XP team then reconsiders all remaining releases and modifies
its plan accordingly.
 Cont’d…
2. Design
• XP design follows the KIS (Keep It Simple) principle.
• A simple design is always preferred over a more complex
representation.
• The design provides implementation guidance for a story as it is
written nothing less, nothing more.
• XP encourages the use of CRC (Class Responsibility Collaborator)
cards as an effective mechanism for thinking about the software is an
object oriented context.
• CRC cards identify and organize the object oriented classes that are
relevant to current software increment.
• The CRC cards are the only design work product produced as a part of
XP process.
 Cont’d…
• If a difficult design is encounter as a part of the design of a story, XP
recommends the immediate creation of that portion of the design
called as ‘spike solution’.
• XP encourages refactoring – a construction technique.
 Cont’d…
3. Coding
• XP recommends that after stories are developed and preliminary
design work is done, the team should not move to code, but rather
develop a series of unit test that will exercise each stories.
• Once the unit test has been created, the developer better able to focus
on what must be implemented to pass the unit test.
• Once the code complete, it can be unit tested immediately, thereby
providing instantaneous feedback to the developer.
• A key concept during the coding activity is pair programming.
• XP recommends that two people work together at one computer
workstation to create code for a story.
• This provides a mechanism for real time problem solving and real
time quality assurance.
 Cont’d…
• As pair programmers complete their work, the code they developed is
integrated with the work of others.
• This continuous integration strategy helps to avoid compatibility and
interfacing problems and provides a smoke testing environment that
helps to uncover errors early.
 Cont’d…
4. Testing
• The creation of unit test before coding is the key element of the XP
approach.
• The unit tests that are created should be implemented using a
framework that enables them to be automated.
• This encourages regression testing strategy whenever code is modified.
• Individual unit tests are organize into a “Universal Testing Suit”,
integration and validation testing of the system can occur on daily
basis.
• This provides the XP team with a continual indication of progress and also can
raise warning flags early if things are going away.
• XP acceptance test, also called customer test, are specified by the
customer and focus on the overall system feature and functionality
that are visible and reviewable by the customer.
 Other Agile Process Models
• The most widely used of all agile process models is Extreme Programming
(XP).
• But many other agile process models have been proposed and are in use
across the industry.
• Among the most common are:
• Adaptive Software Development (ASD)

• Scrum

• Dynamic Systems Development Method (DSDM)

• Crystal Assignment
• Feature Drive Development (FDD)
(10%)
• Lean Software Development (LSD)

• Agile Modeling (AM)

• Agile Unified Process (AUP)

Thank you!
?
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Four

Requirements Engineering
 Introduction
What are Software Requirements?
▪ Requirement is a condition or capability possessed by the software or
system component in order to solve a real world problem.
• The problems can be to automate a part of a system, to correct
shortcomings of an existing system, to control a device, and so on.
❑IEEE defines requirement as :
• (1) A condition or capability needed by a user to solve a problem or
achieve an objective.
• (2) A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
• (3) A documented representation of a condition or capability as in
(1) or (2).’
 Cont’d…
• Requirements describe how a system should act, appear or
perform.
• For this, when users request for software, they provide an
approximation of what the new system should be capable of
doing.
• Requirements differ from one user to another and from one
business process to another.
❑The software requirements are description of features and
functionalities of the target system.
• Requirements convey the expectations of users from the
software product.
 User and System Requirements
• Typically, requirements are presented into two levels of
detail; user and system requirements, where user need a high-
level statement of the requirements, while system developers
need a more detailed system specification.
• So, user and system requirements just refer to different levels
of detail.
• Having different levels of detail is useful because it
communicates information about the system being developed
for different types of readers.
 User Requirements
• It describes the services that the system should provide and
the constraints under which it must operate.
• We don’t expect to see any level of detail, or what exactly the
system will do, It’s more of generic requirements.
• It’s usually written in a natural language and supplied by
diagrams.
 System Requirements
• The system requirements mean a more detailed description of
the system services and the operational constraints such as
how the system will be used and development constraints
such as the programming languages.
• This level of detail is needed by those who are involved in
the system development, like engineers, system architects,
testers, etc.
 Functional & Non-Functional Requirements
• The software requirements are classified into functional
requirements and non-functional requirements.
Functional Requirements
• It covers the main functions that should be provided by the
system.
• When expressed as user requirements, they are usually
described in an abstract way.
• However, more specific functional system requirements
describe the system functions, its inputs, processing; how it’s
going to react to a particular input, and what’s the expected
output.
 Cont’d…
Non-Functional Requirements
• These are the constraints on the functions provided by the
system.
• The constraints, like how many processes the system can
handle (performance), what are the (security) issues the
system needs to take care of.
• The rate of failure (reliability), what are the languages and
tools that will be used (development), what are rules you
need to follow to ensure the system operates within the law
of the organization (legislative).
 Cont’d…
❑Non-functional requirements are often critical than
individual functional requirements.
• Users can usually find ways to work around a system
function that doesn’t really meet their needs.
• However, failing to meet a non-functional requirement can
mean that the whole system is unusable.
➢For example, if an aircraft doesn’t mean meet its reliability
requirements, it won’t be safe for operation, or if an
embedded control system fails to meet its performance
requirements, the control functions won’t operate correctly.
 What is Requirements Engineering (RE) ?

How the customer How the project How the System How the programmer How the business
explained it leader understood it Analyst designed it wrote it Consultant described it

How the project was What operations How the customer How it was supported What the customer
documented installed was billed really need
 Cont’d…
❑Requirements engineering is a process of gathering and
defining what services should be provided by the system.
▪ It focuses on assessing if the system is useful to the business
(feasibility study), discovering requirements (elicitation and
analysis), converting these requirements into some standard
format (specification), and checking that the requirements
define the system that the customer wants (validation).
❑Thus, requirement engineering is the disciplined application
of proven principles, methods, tools, and notation to describe
a proposed system's intended behavior and its associated
constraints.
 Cont’d…
• In practice, requirements engineering isn’t sequential
process, it’s an iterative process in which activities are
interleaved.
• For example, you iterate first on the user requirements;
elicitation, specification, and validation, and repeat the same
steps for the system requirements.
❑Early in the process, most effort will be spent on
understanding high-level business and user requirements.
• Later in the process, more efforts will be spent on elicitation
and understanding detailed system requirements.
 Requirements Engineering Process

• It is a four-step process, which includes:

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
Cont’d…
 Cont’d…
1. Feasibility Study
• The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.

Types of Feasibility:
I. Technical Feasibility -it evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.
II. Operational Feasibility - it assesses the range in which the required
software performs a series of levels to solve business problems and
customer requirements.
III. Economic Feasibility - it decides whether the necessary software can
generate financial profits for an organization.
 Cont’d…
2. Requirement Elicitation and Analysis
• The activity of generating the requirements of a system from
users, customers, and other stakeholders.
• This is also known as the gathering of requirements.
• Here, requirements are identified with the help of customers
and existing systems processes, if available.
• Analysis of requirements starts with requirement elicitation.
• The requirements are analyzed to identify inconsistencies,
defects, omission, etc.
• We describe requirements in terms of relationships and also
resolve conflicts if any.
 Cont’d…
Problems of Elicitation and Analysis
• Getting all, and only, the right people involved is difficult.
• Stakeholders often don't know what they want.
• Stakeholders express requirements in their own terms.
• Stakeholders may have conflicting requirements.
• Requirement may change during the analysis process.
• Organizational and political factors may influence system
requirements.
 Cont’d…
❑The requirements elicitation and analysis has 4 main
process.
• We typically start by gathering the requirements, this could
be done through a general discussion or interviews with
your stakeholders, also it may involve some graphical
notation.
• Then you organize the related requirements into sub-
components and prioritize them, and finally, you refine
them by removing any ambiguous requirements that may
arise from some conflicts.
 Cont’d…

Figure: processes of requirements elicitation and analysis

 Cont’d…
• It shows that it’s an iterative process with feedback from one activity
to another.
• The process cycle starts with requirements discovery and ends with
the requirements document.
• The cycle ends when the requirements document is complete.
 Cont’d…
Requirements Discovery
• It’s the process of interacting with, and gathering the requirements
from, the stakeholders about the required system and the existing
system (if exists).
• Techniques: interviews, scenarios, prototypes, etc.
❑Gathering and understanding the requirements is a difficult
process
• That’s because stakeholders may not know what exactly they want the
software to do, or they may give unrealistic requirements.
• They may give different requirements, which will result in conflict
between the requirements, so we have to discover and resolve these
conflicts.
• Also, there might be some factors that influence the stakeholder’s
decision, like, for example, managers at a company or professors at the
university want to take full control over the management system.
 Cont’d…
Requirements Classification & Organization
• Putting related requirements together, and decomposing the system into
sub-components of related requirements.
• Then, we define the relationship between these components.
• What we do here will help us in the decision of identifying the most
suitable architectural design patterns.
 Cont’d…
Requirements Prioritization & Negotiation
• Eliciting and understanding the requirements is not an easy process.
• One of the reasons is the conflicts that may arise as a result of having different
stakeholders involved.
➢Why? because it’s hard to satisfy all parties if it’s not impossible.
❑This activity is concerned with prioritizing requirements and finding and
resolving requirements conflicts through negotiations until you reach a
situation where some of the stakeholders can compromise.
❑Prioritizing your requirements will help you later to focus on the essentials
and core features of the system, so you can meet the user expectations.
• It can be achieved by giving every piece of function a priority level.
• So, functions with higher priorities need higher attention and focus.
Requirements Specification
• The requirements are then documented
 Cont’d…
3. Software Requirement Specification
• Software requirement specification is a kind of document which is
created by a software analyst after the requirements collected from the
various sources - the requirement received by the customer written in
ordinary language.
• It is the job of the analyst to write the requirement in technical
language so that they can be understood and beneficial by the
development team.
• The models used at this stage include ER diagrams, data flow diagrams
(DFDs), data dictionaries, etc.
 Cont’d…
Data Flow Diagrams (DFDs)
• DFDs are used widely for modeling the requirements.
• DFD shows the flow of data through a system.
• The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of
the preceding.
• The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries
• Data Dictionaries are simply repositories to store information about all
data items defined in DFDs.
• At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the
same definition and terminologies.
 Cont’d…
Entity-Relationship Diagrams
• Another tool for requirement specification is the entity-relationship
diagram, often called an "E-R diagram."
• It is a detailed logical representation of the data for the organization
and uses three main constructs i.e. data entities, relationships, and their
associated attributes.
 Cont’d…
4. Software Requirement Validation
• After requirement specifications developed, the requirements discussed
in this document are validated.
➢The user might demand illegal, impossible solution or experts may
misinterpret the needs.
❑Requirements can be checked against the following conditions.
✓If they can be practically implemented
✓If they are correct and as per the functionality and specially of
software
✓If there are any ambiguities
✓If they are full
✓If they can be demonstrated
 Cont’d…
Requirements Validation Techniques
• Requirements reviews/inspections: systematic manual analysis of the
requirements.
• Prototyping: Using an executable model of the system to check
requirements.
• Test-case generation: Developing tests for requirements to check
testability.
• Automated consistency analysis: checking for the consistency of
structured requirements descriptions.
 Software Requirement Management
• Requirement management is the process of managing changing
requirements during the requirements engineering process and system
development.
• New requirements emerge during the process as business needs a
change, and a better understanding of the system is developed.
• The priority of requirements from different viewpoints changes during
development process.
• The business and technical environment of the system changes during
the development.
 System Models
• System modeling is the process of developing abstract models of a
system, with each model presenting a different view or perspective of
that system.
• System modeling has generally come to mean representing the system
using some kind of graphical notation, which is now almost always
based on notations in the Unified Modeling Language (UML).
• System modelling helps the analyst to understand the functionality of
the system and models are used to communicate with customers
❑Models are used:
• during the requirements engineering process to help derive the
requirements for a system,
• during the design process to describe the system to engineers
implementing the system and
• after implementation to document the system’s structure and operation.
 Cont’d…
❑You may develop models of both the existing system and
the system to be developed:
➢Models of the existing system are used during requirements
engineering.
✓They help clarify what the existing system does and can
be used as a basis for discussing its strengths and
weaknesses.
✓These then lead to requirements for the new system.
 Cont’d…
➢Models of the new system are used during requirements engineering to
help explain the proposed requirements to other system stakeholders.
• Engineers use these models to discuss design proposals and to
document the system for implementation.
❑Different models present the system from different perspectives
• External perspective showing the system’s context or environment
• Behavioural perspective showing the behaviour of the system
• Structural perspective showing the system or data architecture
• Interaction perspective where you model the interactions between a
system and its environment or between the components of a
system.
 Context models
• Context models are used to illustrate the operational context of a
system - they show what lies outside the system boundaries.
• The context of an ATM system
 Data Flow Diagrams
▪ It is a graphical representation of the flow of data.
▪ Data flow diagrams show:
• Data flowing through a system to or from external
entities.
• The processes that transform the data.
• How the data flow from one process to other step by
step
• The data stores that hold the data.
 Why we should Use DFD?
• In describing the boundaries of the system.
• For communicating existing system knowledge to the users.
• A straightforward graphical technique which is easy to
recognize.
• To understand detailed representation of system
components.
• Used as the part of system documentation file.
• Easier to understand by technical and nontechnical
audiences
• Finding out the logic behind the data flow within the
system.
 Components of DFD
• DFD consists principally of four symbols, namely the:
 Process

• Work or actions performed on data (inside the system)

• Labels should be verb phrases
• Receives input data and produces output
 Rule 1: Process
• Can have more than one outgoing data flow or more than one
incoming data flow
 Rule 2: Process
• Can connect to any other symbol (including another process symbol)
Process: Correct/Incorrect?
 Data Flow

• Is a path for data to move from one part of the IS to another

• Arrows indicating movement of data
• Can represent flow between process and data store by two separate
arrows
 Data Store
• Is used in a DFD to represent data that the system stores
• Labels should be noun phrases
 Rule: Data Store
• Must have at least one incoming and one outgoing data flow
 External Entity
• It is origin or destination of data (outside the system)
• Labels should be noun phrases
Rules for Using DFD Symbols
 Levels of DFD
Level 0 Diagram:
• Shows all the processes of the overall system
Level 1 Diagrams
• Shows single process on the level 0 diagram
• Shows how information moves from and to each of these processes.
• Shows in more detail the content of higher level process.
• Level 1 diagrams may not be needed for all level 0 processes.
• Then it may be Level-2 or 3 and so on ..(if required)
 Example
A short brief about the proposed system
• Here we are going to create a DFD for SMS Mela.
➢ The core task of the proposed system that the system will be used to:
• register customer and store customer data
• buy and sell SMS packages.
• create user, packages, categories.
• send SMS via customer.
• manage user and customer.
• store SMS log and data.
• As it is possible to produce a several no of DFD from the above
scenario, here we only represent the DFD which describes user core
tasks with the system.
 Context Diagram of SMS mela API

Registration

Bus SMS
Package
SMS Mela Send SMS

Check
Balance
Level-0 Diagram of SMS mela API
Level-1 Diagram (Buy/add SMS)
 Data Dictionary
• Data dictionary is the centralized collection of information about data.
• It stores meaning and origin of data, its relationship with other data,
data format for usage, etc.
• The data is referenced via data dictionary while designing and
implementing software.
• Data dictionary removes any chances of ambiguity.
 Cont’d...

▪ Data dictionary should contain information about the following:

• Data Flow

• Data Structure

• Data Elements

• Data Stores

• Data Processing

53
Cont’d...
 Example
• Address = House No + (Street / Area) + City + State
• Course ID = Course Number + Course Name + Course Level +
Course Grades

55
 ERD
• Known as Entity Relationship Diagram

• An entity relationship diagram (ERD) shows the relationships of

entity sets stored in a database.

• ER diagrams illustrate the logical structure of databases

• ER-modeling is a data modeling technique used in software

engineering to produce a conceptual data model of a information
system.

• Diagrams created using this ER-modeling technique are called Entity-

Relationship Diagrams, or ER diagrams or ERDs.
 ERD Notations
• To design database there are several important components
which are focused i.e.

• Entity

• Relationship

• Attributes
 ERD Example

ER diagram for Library Management System

 Exercise
1. Precision Tools sells a line of high-quality woodworking
tools. When customers place orders on the company’s Web
site, the system checks to see if the items are in stock, issues a
status message to the customer, and generates a shipping
order to the warehouse, which fills the order. When the order
is shipped, the customer is billed. The system also produces
various reports.
• Draw a context diagram for the order system
• Draw DFD diagram 0 for the order system
59
 Cont’d...
2. Make DFD, ERD for the following
• Hotel Management System
• Inventory Management System
• Hospital Management System
• Railway Reservation System
• Automatic Teller Machine System

60
Thank you !
?
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Five
Software Project Management
 Software Project Management
❖A project is well-defined task, which is a collection of several
operations done in order to achieve a goal (e.g. software development
and delivery).
❖A Project can be characterized as:
✓Project comes with a start and end time.
✓Project is not a routine activity or day-to-day operation.
✓Project needs adequate resources in terms of time, manpower,
finance, material

3
 Cont’d...
▪ Software project management is an essential part of software
engineering.
▪ Projects need to be managed because professional software
engineering is always subject to organizational budget and schedule
constraints.
▪ The success criteria for project management obviously vary from
project to project but, for most projects, important goals are:
✓Deliver the software to the customer at the agreed time.
✓Keep overall costs within budget.
✓Deliver software that meets the customer’s expectations.
✓Maintain a happy and well-functioning development team.

4
 Cont’d...
Life Cycle and Project Management
▪ When a life cycle model is followed project management is
easier.
• For example: The project manager can at any time fairly
accurately tell,
✓ at which stage (e.g., design, code, test, etc.) of the
project is.
✓ How much time would it take to complete

5
 Cont’d...
Project Management Without a Life Cycle Model
▪ It becomes very difficult to track the progress of the
project:
• The project manager would have to depend on the
guesses of the team members.
▪ This usually leads to a problem:
• known as the 99% complete syndrome.

6
 Software Project
▪ It is the complete process of software development from requirement
gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve
intended software product.
▪ A set of activities undertaken within a defined time period in order to
meet a specific set of goals/objectives within a budget.
❑ Projects are different from standard business operational activities as
they:
✓Are unique in nature: they do not involve repetitive processes.
• Every project undertaken is different from the last, whereas
operational activities often involve undertaking repetitive (identical)
processes
✓ Have a defined timescale: projects have a clearly specified start and
end date within which the deliverables must be produced to meet a
specified customer requirement
7
 Cont’d...
✓Have an approved budget: projects are allocated a level of financial
expenditure within which the deliverables must be produced to meet a
specified customer requirement
✓Have limited resources: at the start of a project, an agreed amount of
labor, equipment and materials is allocated to the project
✓Involve an element of risk: projects entail a level of uncertainty and
therefore carry business risk.
✓Achieve beneficial change: the purpose of a project, typically, is to
improve an organization through the implementation of business
change.

8
 Cont’d...
❖A project generally exhibits most of the following conditions:
✓ It is finite
✓ Usually complex
✓ Non-repetitive
✓ Requires resources

9
 Cont’d...
❖The image below shows triple constraints for software projects.
❖It is an essential part of software organization to deliver quality
product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled.

10
 Project Stakeholders
❑Project stakeholders are individuals and organizations that are
actively involved in the project.
▪ Key Stakeholders include:
✓ Project manager: the individual responsible for managing the
project.
✓ Customer: the individual or organization that will use the
project's product or service.
✓ Project team members: the group that is performing the work of
the project.
✓ Sponsor: the individual or group that provides the financial
resources for the project.

11
 Project Planning
▪ Carried out before development starts.
▪ The project plan guides execution
▪ Key outputs include:
✓ A work breakdown structure (WBS)
✓ A project schedule, in the form of a Gantt chart with all
dependencies and resources entered
✓ A list of prioritized risks

12
 Cont’d...
❑Important activities:
✓ Estimation: Effort, cost, resource, and project duration
✓ Scheduling
✓ Staffing
✓ Risk management: identification, analysis, and abatement
procedures
✓ Miscellaneous plans: quality assurance plan, configuration
management plan, etc.

13
 Types of plan
▪ Software development plan: the central plan, which describes how
the system will be developed.
✓ Specifies the order of work to be carried out, resources,
responsibilities, and so on.
▪ Quality assurance plan: specifies the quality procedures & standards
to be used.
▪ Validation plan: defines how a client will validate the system that has
been developed.
▪ Configuration management plan: defines how the system will be
configured and installed.
▪ Maintenance plan: defines how the system will be maintained.
▪ Staff development plan: describes how the skills of the participants
will be developed.
14
 Cont’d…
Development plan should contain:
1. Introduction: brief introduction to project
2. Project organization: intro to organizations, people, and their roles
3. Risk Analysis: what are the key risks to the project?
4. Hardware and software resources: what Hardware and Software
resources will be required for the project and when
5. Work breakdown: the project divided into activities, milestones,
deliverables, dependencies between tasks etc.
6. Project schedule: actual time required - allocation of dates
7. Reporting and progress measurement: mechanisms to monitor
progress.

15
 Organization of SPMP Document
▪ Introduction:
• (Objectives,Major Functions,Performance Issues,Management and
Technical Constraints)
▪ Project Estimates
• (Historical Data,Estimation Techniques,Effort, Cost, and Project
Duration Estimates)
▪ Project Resources Plan
• (People,Hardware and Software,Special Resources)
▪ Schedules
• (Work Breakdown Structure,Task Network, Gantt Chart
Representation,PERT Chart Representation)
16
 Cont’d...
▪ Risk Management Plan
• (Risk Analysis,Risk Identification,Risk Estimation,Abatement
Procedures)
▪ Project Tracking and Control Plan
▪ Miscellaneous Plans
• (Quality Assurance)

17
In What Ways Management of Software Projects Differ
from Management of Engineering Systems?

▪ Intangible:
✓ Software is invisible till it is ready and runs
▪ Large Change Impact:
✓ A small change request can have terrible impact
✓ Change is the rule rather than exception
▪ Intellectual work
18
Why Software Project Management is Hard?
▪ Management of intellectual and complex work
▪ It is hard to manage anything that you cannot see
▪ Changing customer requirements
▪ Manpower turnover

19
 Common Mistakes why Projects FAIL
▪ Project managers begin without knowing what the project is.
▪ Project managers do not have a plan.
▪ Project managers do not break the project down to manageable
pieces.

20
 What is management?
❑Management involves the following activities:
✓Planning: deciding what is to be done, Estimate and schedule
resources
✓Organizing: making arrangements, Who does what
✓Staffing: selecting the right people for the job, Recruiting and
motivating personnel
✓Directing: giving instructions, Ensure team acts as a whole
✓Monitoring: checking on progress, revising plans
✓Controlling: taking action to remedy hold-ups
✓Innovating: coming up with solutions when problems emerge
✓Representing: liaising with clients, users, developers and other
stakeholders
21
 Responsibility of project managers
❖Project proposal writing,

❖Project cost estimation,

❖ Scheduling,

❖Project staffing,

❖ Project monitoring and control,

❖Software configuration management,

❖Risk management,

❖Managerial
22 report writing and presentations, etc.
 Setting objectives
▪ Answering the question ‘What do we have to do to have a
success?
❑Objectives should be SMART
✓S -specific, that is, concrete and well-defined
✓M -measurable, that is, satisfaction of the objective can be
objectively judged
✓A -achievable, that is, it is within the power of the individual or
group concerned to meet the target
✓R -relevant, the objective must be relevant to the true purpose of the
project
✓T -time constrained: there is defined point in time by which the
objective should be achieved
23
 SOFTWARE SCOPE
▪ Software Scope is defined in collaboration with the User
Management by asking the following Questions on the
following areas:-
✓ Software Context,

✓ Information Objectives

✓ Function and Performance of Software

▪ Software Poject Scope must be Unambigious and

understandable at the Management and Technical level

24
 Project Estimation
▪ For an effective management, accurate estimation of
various measures is a must.
▪ With the correct estimation, managers can manage and
control the project more efficiently and effectively.
▪ Project estimation may involve the following:
• Software size estimation
• Effort estimation
• Time estimation
• Cost estimation

25
 Software size estimation
▪ Software size may be estimated either in terms of KLOC
(Kilo Line of Code) or by calculating number of function
points in the software.

Effort estimation
▪ The manager estimates efforts in terms of personnel
requirement and man-hour required to produce the
software.
▪ For effort estimation software size should be known.

26
 Time estimation
▪ Once size and efforts are estimated, the time required to
produce the software can be estimated.
▪ Software tasks are divided into smaller tasks, activities or
events by Work Breakdown Structure (WBS).
▪ The tasks are scheduled on day-to-day basis or in calendar
months.

27
 Cost estimation
▪ This might be considered as the most difficult of all because it
depends on more elements than any of the previous ones.
▪ For estimating project cost, it is required to consider:
• Size of the software
• Software quality
• Hardware
• Additional software or tools, licenses etc.
• Skilled personnel with task-specific skills
• Travel involved
• Communication
• Training and support 28
 Estimation techniques
• Expert judgement
• Estimation by analogy
• Parkinson's Law
• Pricing to win
• Algorithmic cost modelling
• Top-down and bottom up

29
 1. Expert judgement
• One or more experts in both software development and the
application domain use their experience to predict software
costs.
• Process iterates until some consensus is reached.
▪ Advantages:
• Relatively cheap estimation method.
• Can be accurate if experts have direct experience of
similar systems
▪ Disadvantages:
• Very inaccurate if there are no experts!

30
 2. Estimation by analogy
▪ The cost of a project is computed by comparing the project
to a similar project in the same application domain.
• ➔ software size, effort, or cost of a comparable project
from the past
▪ Advantages:
• Accurate if project data available
▪ Disadvantages:
• Impossible if no comparable project has been tackled.
Needs systematically maintained cost database

31
 3. Pricing to win
▪ The project costs whatever the customer has to
spend on it
▪ Advantages:
• You get the contract
▪ Disadvantages:
• The probability that the customer gets the system he or
she wants is small. Costs do not accurately reflect the
work required.

32
 4. Parkinson's Law
▪ The project costs whatever resources are available
Advantages:
• it helps to distribute the project development time among
different activities in a balanced manner without any
additional overspend
Disadvantages:
• System is usually unfinished

33
 5. Bottom-up versus top-down
❑ Bottom-up : Start at the component level and estimate the effort
required for each component.
▪ Add these efforts to reach a final estimate
✓ use when no past project data
✓ identify all tasks that have to be done – so quite time-consuming
✓ use when you have no data about similar past projects
❑ Top-down : Start at the system level and assess the overall system
functionality and how this is delivered through sub-systems.
✓ produce overall estimate based on project cost drivers
✓ based on past project data
✓ divide overall estimate between jobs to be done
34
 COnstructive COst Model (COCOMO)
▪ Actually three different models :
1. THE BASIC MODEL: a gross estimator that does not take
individual complexity characteristics into account.
2. THE INTERMEDIATE MODEL: considers 15 factors that
are called “cost driver attributes”
3. THE DETAILED MODEL: introduces “phase sensitive
effort multipliers” that enable the estimate to be modified
and updated as the project continues.

35
COCOMO : Basic Model

36
 Cont’d...
▪ Organic mode (application programs) : relatively small,
simple SW projects (e.g. Thermal analysis program)
▪ Semi-detached mode ( utility programs): an
intermediate (in size and complexity) SW projects with
mixed experience, mixed requirements
▪ Embedded mode (system programs) – developed within
tight HW, SW and operational constraints (flight control
SW for aircraft)

37
 Cont’d…
Example:1
▪ Assume that the size of semi-detached software product has been
estimated to be 33,300 lines of source code.
▪ Determine the effort required to develop the software product and
the nominal development time.
Solution:
• The estimated number of lines of code is : 33.3 KLOC
Project type is : semi-detached
Therefore,
pm = 3.0* KLOC1.12 = 3.0 (33.3) 1.12 = 152 person-months
To compute development time :
tdev = 2.5 pm0.35 = 2.5 (152)0.35 = 14.5 months
38
 Cont’d…
Example:2
▪ Assume that the size of an organic type software product has been
estimated to be 32,000 lines of source code.
▪ Assume that the average salary of software engineers be ETB. 15,000
per month.
▪ Determine the effort required to develop the software product and the
nominal development time.
Solution
• From the basic COCOMO estimation formula for organic software:
Effort = 2.4 х (32)1.05 = 91 PM
Nominal development time = 2.5 х (91)0.38 = 14 months
Cost required to develop the product = 14 х 15,000 = 210,000 Birr
39
 COCOMO: Intermediate Model
▪ There are 15 different attributes, called cost driver attributes,
that determine the multiplying factors.
▪ These factors depend on product, computer, personnel, and
technology (project) attributes.
▪ Each cost driver has a rating scale (very low, low, nominal,
high, very high and extra high ).
Software Project a b

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20 40

Effort multipliers for different cost drivers.

41
 Steps
1) Determine the initial estimate (nominal estimate) of the
development effort from the estimate of thousands of
lines of source code (KLOC).
→ Ei = a * (KLOC) b
2) Determine a set of 15 multiplying factors from different
attributes of the project, and compute the effort
adjustment factor (EAF).
→ EAF = product of all the 15 multiplying factors.
3) Compute the total effort by multiplying the initial effort
with the effort adjustment factor.
→ Total effort = Ei * EAF
42
 Cont’d…
• Assume 4 modules are to be contained in a project.
• Assume the project is organic.
• The modules are
M1 = 0.5 KLOC, M2 = 0.5 KLOC, M3 = 0.3 KLOC, and M4 = 0.7
KLOC.
❑And the multiplying factors are:
✓RELY, required reliability is …. very high
✓CPLX, product complexity is…. high
✓STOR, main storage constraint is … high
✓Others are … nominal
❑Calculate: i) The initial effort
ii) The total effort 43
 Cont’d…
Solution:
• size = M1 + M2 + M3 + M4
= 2 KLOC
• For organic project a = 3.2, b = 1.05
Ei = a * (size) b
= 6.72
• Total Effort = Ei * EAF; Where
EAF =1.40 * 1.15 * 1.06 * 1 = 1.71
Total Effort =6.72 *1.71
= 11.5 PM 44
 Exercise
❑ Suppose a system for office automation has to be designed.
From the requirements, it is clear that there will be four major
modules in the system: data entry, data update, query, and report
generator. It is also clear from the requirements that this project
will fall in the organic category. The sizes for the different
modules and the overall system are estimated to be:
• Data Entry 0.6 KLOC
• Data Update 0.6 KLOC
• Query 0.8 KLOC
• Reports 1.0 KLOC
• TOTAL 3.0 KLOC
45
 Cont’d...
▪ From the requirements, the ratings of the different cost
driver attributes(multiplier) are assessed
• Complexity High 1.15
• Storage High 1.06
• Experience Low 1.13
• Programmer Capability Low 1.17.
▪ Based on this value what is the estimated effort by person
month
• Ei =? a * KLOCb
• EAF= ?
• E= Ei * EAF
46
 Project Scheduling and Staffing
▪ As well as effort estimation, managers must estimate the
calendar time required to complete a project and when staff
will be required.
▪ Once the effort is estimated, various schedules (or project
duration can be developed.
▪ For example, for a project whose effort estimate is 56
person-months, schedule of 8 months is possible with 7
people.
▪ A schedule of 7 months with 8 people is also possible, as is
a schedule of approximately 9 months with 6 people.
▪ The time required is independent of the number of people
working on the project➔ not fully interchangeable 47
 PROJECT SCHEDULING
• Project-task scheduling is an important project planning activity.
• It involves deciding which tasks would be taken up when.
• In order to schedule the project activities, a software project manager
needs to do the following:
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to
complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path.
• A critical path is the chain of activities that determines the duration of the
project. 48
 Gantt Chart
• Gantt chart was devised by Henry Gantt (1917).
• It represents project schedule with respect to time periods.
• It is a horizontal bar chart with bars representing activities and time
scheduled for the project activities.

49
 Why Are Projects Late?
✓an unrealistic deadline established by someone outside the
software development group
✓ changing customer requirements that are not reflected in
schedule changes;
✓predictable and/or unpredictable risks that were not considered
when the project commenced;
✓technical difficulties that could not have been foreseen in
advance
✓human difficulties that could not have been foreseen in advance;
✓miscommunication among project staff that results in delays;
✓a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the
problem
50
 Staffing( team structure)
▪ Detailed scheduling is done only after actual assignment of people has
been done.
▪ project's team is led by a project manager, who does the planning and
task assignment.
▪ is responsible for all major technical decisions of the project.
▪ The teams are structured hierarchically, consists of analyzer,
programmers, testers, a configuration controller, quality controller, and
possibly a librarian for documentation.
▪ Generally the team structure is determined by
• The Management style of the organization;
• The number of people, who will populate the team, and their skill
levels
• The overall problem difficulties.
51
 Cont’d...
▪ Project Factors that should be considered when Planning the
structure of Teams.
1. The difficulty of the ‘Problem” to be solved
2. The ‘’Size’’ of the resultant programs in terms of Line Code
(LOC) or Function Points (FP)
3. The “Time” that the Team will stay together (Team Lifetime)
4. The degree to which the problem can be modularised.
5. The required Quality and Reliability of the System to be built
6. The rigidity of the Delivery Date
7. The degree of Sociability (Communication) required for the
Project.
52
 Cont’d...
▪ Group communication: which affects the progress of the
project
❑Several factors affect communications in a group
✓ Status of the group members
• Higher-status members tend to dominate communications
with lower status members
✓Personalities in the group
• If there are too many people in the group who are task-
oriented, this may inhibit effective communications (all are
concentrated on technical issues and nobody discusses
problems) 53
 Cont’d...
✓Sexual composition of the group
• Studies have shown that men and women prefer to work
in mixed-sex groups.
• Within these groups, communications are better than in
single-sex groups
✓ Communication channels
• Communications are more effective if anyone in a
group can easily contact anyone else

54
 Team Structure
• We consider only three team structures:
• Democratic,
• Chief programmer,
• Mixed team

55
 Chief programmer teams
• Fred Brooks was concerned about the need to maintain ‘design
consistency’ in large software systems
• Appointment of key programmers, Chief Programmers, with
responsibilities for defining requirements, designing, writing and test
software code
• Assisted by a support team: co-pilot – shared coding, editor who
made typed in new or changed code, program clerk who wrote and
maintained documentation and tester
• Problem – finding staff capable of the chief programmer role

56
 Democratic Team
• Does not enforce any formal team hierarchy.
• Decisions are taken based on discussions,
• any member is free to discuss with any other member
• Since a lot of debate and discussions among the team
members takes place,
• for large team sizes significant overhead is incurred

57
 Mixed Control Team Structure
• Incorporates both hierarchical reporting and democratic
set up.

58
 Risk management
• The planning for risk includes these steps:
• Risk identification – what risks might there be?
• Risk analysis and prioritization – which are the most
serious risks?
• Risk planning – what are we going to do about them?
• Risk monitoring – what is the current state of the risk?

59
 Boehm’s top 10 development risks
Risk Risk reduction techniques

Personnel Staffing with top talent; job matching; teambuilding;

shortfalls training and career development; early scheduling
of key personnel

Unrealistic time Multiple estimation techniques; design to cost;

and cost incremental development; recording and analysis
estimates of past projects; standardization of methods

Developing the Improved software evaluation; formal specification

wrong methods; user surveys; prototyping; early user
software manuals
functions
Developing the Prototyping; task analysis; user involvement
wrong user 60
interface
 Cont’d…
Gold plating Requirements scrubbing, prototyping,
design to cost
Late changes to Change control, incremental development
requirements
Shortfalls in externally Benchmarking, inspections, formal
supplied components specifications, contractual agreements,
quality controls
Shortfalls in externally Quality assurance procedures, competitive
performed tasks design etc
Real time performance Simulation, prototyping, tuning
problems
Development Technical analysis, cost-benefit analysis,
technically too difficult prototyping , training
61
Thank You!
?
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Six

Software Design
 Software Design
▪ Software design deals with transforming the customer requirements,
as described in the SRS document, into a form (a set of documents)
that is suitable for implementation in a programming language.

▪ More creative than analysis

▪ Problem solving activity

▪ Design phase transforms SRS document:

• to a form easily implementable in some programming language.
 Cont’d.
• For assessing user requirements, an SRS (Software Requirement
Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements in software terms.

• The output of this process can directly be used into implementation in

programming languages.
 Software Design Levels
• Software design yields three levels of results:

A) Architectural Design

• The architectural design is the highest abstract version of the system.

• It identifies the software as a system with many components interacting

with each other.

• At this level, the designers get the idea of proposed solution domain.

B) High-level Design

• The high-level design breaks the ‘single entity-multiple component’

concept of architectural design into less-abstracted view of sub-systems
and modules and depicts their interaction with each other.
 Cont’d...
• High-level design focuses on how the system along with all of its
components can be implemented in forms of modules.

• It recognizes modular structure of each sub-system and their relation

and interaction among each other.

C) Detailed Design

• Detailed design deals with the implementation part of what is seen as a

system and its sub-systems in the previous two designs.

• It is more detailed towards modules and their implementations.

• It defines logical structure of each module and their interfaces to

communicate with other modules.
 Analysis Vs Design
▪ An analysis technique helps to elaborate the customer requirements
through careful thinking:
• And at the same time consciously avoids making any decisions
regarding implementation.
▪ The design model is obtained from the analysis model through
transformations over a series of steps:
• Decisions regarding implementation are consciously made.
 Design Principles
• The design should minimize the intellectual distance between the
software and the problem in the real world.

• The design should exhibit uniformity and integration.

• The design should be structured to accommodate change.

• Design is not coding, coding is not design.

• The design should be assessed for quality.

• The design should be reviewed to minimize conceptual errors.

 Goals of a Good Design
• The design must be a readable and understandable guide for those
who generate code, and for those who test and support the software.
• The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.
 Cont’d…
❑The goals during the design phase are:
• Choosing the best possible design (in terms of time, complexity,
space, etc.)
• Completeness: - implements all the specifications.
• Efficiency: - optimal use of scarce resources by the system.
• Simplicity: - easily understandable design; shouldn’t be complex;
unless simple, collecting and fixing bugs will be difficult; makes
maintenance easier.
• Modularity: - implementing partitioning.
• If a system is partitioned into modules so that the modules are
solvable and modifiable separately.
 Modularity
• Modularity is a fundamental attributes of any good design.
• Decomposition of a problem cleanly into modules:
• Modules are almost independent of each other.
• Divide and conquer principle.
❑In technical terms, modules should display:
• High cohesion
• Low coupling.
• A module consists of:
• Several functions,
• Associated data structures.
 Cohesion and Coupling
• Cohesion is a measure of:
✓ functional strength of a module.
• A cohesive module performs a single task or function.
• Coupling between two modules is:
• A measure of the degree of the interdependence or interaction
between the two modules.
• A module having high cohesion and low coupling is:
• functionally independent of other modules:
• A functionally independent module has minimal interaction with
other modules.
 Cont’d...

Fig. Module coupling

❑This can be achieved as:
• Controlling the number of parameters passed amongst modules.
• Avoid passing undesired data to calling module.
• Maintain parent / child relationship between calling & called modules.
• Pass data, not the control information.
 Cont’d...
• Consider the example of editing a student record in a ‘student
information system’.

Fig. Example of coupling

 Design Approaches
▪ Two fundamentally different software design approaches:
I. Function-oriented design
II. Object-oriented design
 I. Function-Oriented Design
• A system is looked upon as something that performs a set of
functions.
• Starting at this high-level view of the system:
• Each function is successively refined into more detailed
functions.
• Functions are mapped to a module structure.
 Example
• The function create-new-library- member:
• Creates the record for a new member,
• Assigns a unique membership number
• Prints a bill towards the membership
• Create-library-member function consists of the following sub-
functions:
• Assign-membership-number
• Create-member-record
• Print-bill
 2. Object-Oriented Design
▪ System is viewed as a collection of objects (i.e. entities).
▪ System state is decentralized among the objects:
• Each object manages its own state information.
▪ Objects have their own internal data:
• Defines their state.
▪ Similar objects constitute a class.
• Each object is a member of some class.
▪ Classes may inherit features from a super class.
▪ Conceptually, objects communicate by message passing.
 Software Architecture
▪ Software architecture is the structure of the components of the
solution.
▪ A particular software architecture decomposes a problem into smaller
pieces and attempts to find a solution (Component) for each piece.
 Why we need Software Architecture?
▪ Real-world systems are large and complex.
▪ Need to divide-and-conquer.
▪ Software architecture is used for:
• Distributing work to teams for developing components
(in parallel)
• Integrating components
• Planning and defining strategies for software testing
• Understanding the “big-picture” of the system
 Software User Interface Design
▪ User interface is the front-end application view to which user
interacts in order to use the software.
▪ User can manipulate and control the software as well as
hardware by means of user interface.
▪ User interface is part of software and is designed in such a
way that it is expected to provide the user insight of the
software.
▪ UI provides fundamental platform for human-computer
interaction.
 Cont’d...
❖The software becomes more popular if its user interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interfacing screens
• UI is broadly divided into two categories:
• Command Line Interface
• Graphical User Interface
 Command Line Interface (CLI)
▪ CLI has been a great tool of interaction with computers until
the video display monitors came into existence.
▪ CLI is first choice of many technical users and programmers.
▪ It is the minimum interface a software can provide to its
users.
▪ CLI provides a command prompt, the place where the user
types the command and feeds to the system.
▪ The user needs to remember the syntax of command and its
use.
 Cont’d...
❖A text-based command line interface can have the following elements:

➢ Command Prompt

• It is text-based notifier that is mostly shows the context in which the user is working.

• It is generated by the software system.

➢ Cursor

• It is a small horizontal line or a vertical bar of the height of line, to represent position
of character while typing.

• Cursor is mostly found in blinking state.

• It moves as the user writes or deletes something.

➢ Command

• A command is an executable instruction.

• It may have one or more parameters.

 Graphical User Interface
▪ Graphical User Interface (GUI) provides the user graphical means to
interact with the system.
▪ Typically, GUI is more resource consuming than that of CLI.
▪ With advancing technology, the programmers and designers create
complex GUI designs that work with more efficiency, accuracy, and
speed.
 GUI Elements
▪ GUI provides a set of components to interact with software or
hardware.
▪ Every graphical component provides a way to work with the system.
▪ A GUI system has following elements such as:
 Reading Assignment
Types of module coupling Types of module Cohesion

• Data coupling  Coincidental Cohesion

 Logical Cohesion
• Stamp coupling
 Temporal Cohesion
• Control coupling
 Procedural Cohesion
• Common coupling
 Communicational Cohesion
• Content coupling
 Sequential Cohesion

 Functional Cohesion
 DMIoT, School of Computing
Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
Chapter Seven

Coding
 Coding
• Coding is the process of transforming the design of a system into a
computer language format.
• This coding phase of software development is concerned with software
translating design specification into the source code.
• It is necessary to write source code & internal documentation so that
conformance of the code to its specification can be easily verified.
• Coding is done by the coder or programmers who are independent
people than the designer.
• The goal is not to reduce the effort and cost of the coding phase, but to
cut to the cost of a later stage.
• The cost of testing and maintenance can be significantly reduced with
efficient coding.
 Goals of Coding
1. To translate the design of system into a computer language format:

• The coding is the process of transforming the design of a system into a

computer language format, which can be executed by a computer and that
perform tasks as specified by the design of operation during the design phase.

2. To reduce the cost of later phases:

• The cost of testing and maintenance can be significantly reduced with

efficient coding.

3. Making the program more readable

• Program should be easy to read and understand.

• It increases code understanding having readability and understandability as a

clear objective of the coding activity can itself help in producing more
maintainable software.
 Cont’d…
• For implementing our design into code, we require a high-level
functional language.

• A programming language should have the following characteristics:

 Characteristics of Programming Language
• Following are the characteristics of Programming Language:
 Cont’d…
❑Readability: A good high-level language will allow programs to be
written in some methods that resemble a quite-English description of
the underlying functions.

• The coding may be done in an essentially self-documenting way.

❑Portability: High-level languages, being virtually machine-

independent, should be easy to develop portable software.

❑Generality: Most high-level languages allow the writing of a vast

collection of programs, thus relieving the programmer of the need to
develop into an expert in many diverse languages.
 Cont’d…
❑Brevity: Language should have the ability to implement the algorithm with
less amount of code.

• Programs mean in high-level languages are often significantly shorter than

their low-level equivalents.

❑Error checking: A programmer is likely to make many errors in the

development of a computer program.

• Many high-level languages invoke a lot of bugs checking both at compile-

time and run-time.

❑Cost: The ultimate cost of a programming language is a task of many of its

characteristics.

❑Quick translation: It should permit quick translation.

 Cont’d…
❑Efficiency: It should authorize the creation of an efficient object code.

❑Modularity: It is desirable that programs can be developed in the

language as several separately compiled modules, with the appropriate
structure for ensuring self-consistency among these modules.

❑Widely available: Language should be widely available, and it should

be feasible to provide translators for all the major machines and all the
primary operating systems.

• A coding standard lists several rules to be followed during coding, such

as the way variables are to be named, the way the code is to be laid out,
error return conventions, etc.
 Coding Standards (Conventions)
• Programmers spend more time reading code than writing code.

• Coding standards provide rules and guidelines for some aspects

of programming in order to make code easier to read and
understand.

❑Provide guidelines for programmers regarding:

• naming,
• file organization,
• statements and declarations,
• layout and comments.
 Cont’d…
• General coding standards refers to how the developer writes code, so
here we will discuss some essential standards regardless of the
programming language being used.
• The following are some representative coding standards:
 Cont’d…
1. Indentation: Proper and consistent indentation is essential in
producing easy to read and maintainable programs.

▪ Indentation should be used to:

• Emphasize the body of a control structure such as a loop or a select

statement.

• Emphasize the body of a conditional statement

• Emphasize a new scope block

 Cont’d…
2. Inline comments: Inline comments analyze the functioning of the
subroutine, or key aspects of the algorithm shall be frequently used.

3. Rules for limiting the use of global: These rules file what types of
data can be declared global and what cannot.

4. Structured Programming: Structured (or Modular) Programming

methods shall be used. "GOTO" statements shall not be used as they
lead to "spaghetti" code, which is hard to read and maintain, except as
outlined line in the FORTRAN Standards and Guidelines.
 Cont’d…
5. Naming conventions for global variables, local variables, and
constant identifiers:

• A possible naming convention can be that global variable names

always begin with a capital letter, local variable names are made of
small letters, and constant names are always capital letters.

6. Error return conventions and exception handling system:

• Different functions in a program report the way error conditions are

handled should be standard within an organization.

• For example, different tasks while encountering an error condition

should either return a 0 or 1 consistently.
 Cont’d…
Summary on Naming Conventions:
• Package names should be in lower case (e.g., mypackage,
edu.iitk.maths)
• Type names should be nouns and should start with uppercase
(e.g., Day, DateOfBirth, Event Handler)
• Variable names should be nouns starting with lower case
(e.g., name, amount)
• Constant names should be all uppercase (e.g., PI,
MAX_ITERATIONS)
• Method names should be verbs starting with lowercase (e.g.,
getValue())
 Cont’d…
Benefits of Coding Standards/Conventions:

▪ Having strong Coding Conventions/Standards used:

• People can stop reformatting code and renaming variables and
methods whenever working on code written by other people.

• It's slightly easier to understand code that is consistently formatted

and uses a consistent naming standard.

• It's easier to integrate modules that use a common consistent

naming standard.

➢less need to look up and cross-reference the different names

that refer to the same thing.
 Programming Principles and Guidelines
▪ Programmer is anybody who knows the syntax of a language and
can write code that do some thing.

• Writing solid code is a skill that can only be acquired by practice.

• Software engineer is someone who not only writes code that

works correctly, but also writes high quality code.
• Responsible to produce software that has a business asset and is going to
last for many years.

• The goal should be correctness and economy (the software should not
make excessive use of time or space)
 Cont’d…
High quality code has the following characteristics:

• Maintainability (easy to find and fix bugs, easy to add new features)

• Readability (easy to read)

• Understandability (easy to understand – this is not the same as readability,

e.g. redundant and repetitive code may be very readable, but not necessarily
easily understandable)

• Reusability (easy to reuse parts of code, e.g. functions, classes, data

structures, etc)

• Robustness (code that can handle unexpected inputs and conditions)

• Reliability (code that is unlikely to produce wrong results; it either works

correctly, or reports errors).
 Cont’d…
• Based on experience, some general rules and guidelines can be given for the
engineers.

• Some times there are some complains by some people ➔ “limits creativity”,
this works if the system is developed in one person like “hacking”

• But dealing with large system that involves number of engineers, there
should be some standard which creates:

• Good communication

• Better understanding

• Engineers should be creative with algorithms and data structures, rather than
being “creative” with the coding style and language tricks.
 Cont’d…
• General coding guidelines provide the programmer with a set of the
best methods which can be used to make programs more comfortable
to read and maintain.
• Most of the examples use the C language syntax, but the guidelines can
be tested to all languages.
• The following are some representative coding guidelines recommended
by many software development organizations.
Cont’d…
 Cont’d…
1. Line Length: It is considered a good practice to keep the length of
source code lines at or below 80 characters.
• Lines longer than this may not be visible properly on some terminals
and tools. Some printers will truncate lines longer than 80 columns.
2. Spacing: The appropriate use of spaces within a line of code can
improve readability.
3. The code should be well-documented: As a rule of thumb, there
must be at least one comment line on the average for every three-
source line.
 Cont’d…
4. The length of any function should not exceed 10 source lines:
• A very lengthy function is generally very difficult to understand as it
possibly carries out many various functions.
• For the same reason, lengthy functions are possible to have a
disproportionately larger number of bugs.
5. Do not use goto statements: Use of goto statements makes a
program unstructured and very tough to understand.
6. Inline Comments: Inline comments promote readability.
7. Error Messages: Error handling is an essential aspect of computer
programming.
• This does not only include adding the necessary logic to test for and
handle errors but also involves making error messages meaningful.
 Cont’d…
Programming Style
• Programming style refers to the technique used in writing the source
code for a computer program.
• Most programming styles are designed to help programmers quickly
read and understands the program as well as avoid making errors.
(Older programming styles also focused on conserving screen space.)
• A good coding style can overcome the many deficiencies of a first
programming language, while poor style can defeat the intent of an
excellent language.
• The goal of good programming style is to provide understandable,
straightforward, elegant code.
• The programming style used in a various program may be derived from
the coding standards or code conventions of a company or other
computing organization, as well as the preferences of the actual
programmer.
 Cont’d…
Some general rules or guidelines in respect of programming style:
 Cont’d…
1. Clarity and simplicity of Expression: The programs should be
designed in such a manner so that the objectives of the program is clear.
2. Naming: In a program, you are required to name the module,
processes, and variable, and so on.
• Care should be taken that the naming style should not be cryptic and
non-representative.
For Example: a = 3.14 * r * r
area of circle = 3.14 * radius * radius;
3. Control Constructs: It is desirable that as much as a possible single
entry and single exit constructs used.
4. Information hiding: The information secure in the data structures
should be hidden from the rest of the system where possible.
• Information hiding can decrease the coupling between modules and
make the system more maintainable.
 Cont’d…
5. Nesting: Deep nesting of loops and conditions greatly harm the static
and dynamic behavior of a program.
• It also becomes difficult to understand the program logic, so it is
desirable to avoid deep nesting.
6. User-defined types: Make heavy use of user-defined data types like
enum, class, structure, and union. These data types make your program
code easy to write and easy to understand.
7. Module size: The module size should be uniform. The size of the
module should not be too big or too small. If the module size is too large,
it is not generally functionally cohesive.
• If the module size is too small, it leads to unnecessary overheads.
 Cont’d…
8. Module Interface: A module with a complex interface should be
carefully examined.
9. Side-effects: When a module is invoked, it sometimes has a side effect
of modifying the program state.
• Such side-effect should be avoided where as possible.
 Coding Process
• Before starting coding determine the approach, top-down or bottom-up
• assign modules to developer, they use some process to develop the code.

• We have to perform Refactoring process.

• It is a technique to improve existing code and prevent this design decay
with time

• Verification and validation: a module has to be verified before it

is used by others.
• Like correct /error free.(testing, inspection)

• Generally software coding principle should be KISS.

• Keep it simple - always easier to read and maintain (and debug!)
Cont’d…
 Cont’d…
Benefit from KISS
• You will be able to solve more problems, faster.
• You will be able to produce code to solve complex problems
in fewer lines of code.
• You will be able to produce higher quality code.
• You will be able to build larger systems, easier to maintain
• You're code base will be more flexible, easier to extend,
modify or refactor when new requirements arrive
• You will be able to achieve more than you ever imagined
• You will be able to work in large development groups and
large projects since all the code is stupid simple
 Software Metrics
• A software metric is a measure of software characteristics
which are measurable or countable.
• Software metrics are valuable for many reasons, including
measuring software performance, planning work items,
measuring productivity, and many other uses.
• Used to ensure that the final product has a high quality and
productivity.
• Within the software development process, many metrics are
that are all connected.
• Software metrics are similar to the four functions of
management: Planning, Organization, Control, or
Improvement.
 Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics:-These are the measures of various characteristics
of the software product.
• The two important software characteristics are:
i. Size and complexity of software.
ii. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics
• These are the measures of various characteristics of the software
development process.
• For example, the efficiency of fault detection.
• They are used to measure the characteristics of methods, techniques,
and tools that are used for developing software.
 Verification & Validation
Verification (Process Oriented)

• Is the process of determining whether the output of one

phase of software development conforms to that of its
previous phase.

• Refers to the set of activities that ensure that software

correctly implements a specific function.

• It is a static testing strategies.

• Involves code walk-through, Inspections and reviews

 Cont’d...
CODE REVIEW
• It is done after the module successfully compiled and all
syntax errors are eliminated.
• Used for reducing coding error.
Code Walk-Through
• It is an informal code analysis technique
• Main objective is to discover the algorithmic and logical
errors in the code.
• Some developers are given the code to read and understand
before the code walk-through meeting.
• Each member of the team selects some test cases to
simulate the execution manually.
 Cont’d...
Code Inspection
• to discover some common type of errors due to oversight or
improper programming.

• Good s/w companies collect statistics to identify the type of

errors most frequently committed by their engineers.
 Validation (Product oriented)
• Is the process of determining whether the fully developed
system conforms to its requirement specifications.

• Refers to a different set of activities that ensure that the

software that has been build is traceable to customer
requirement.

• Aim is to ensure that the final product is error free.

• Require Black Box testing techniques.