Chapter One: Basics of Software Engineering

Chapter one
Basics of Software engineering
6/13/2017 Basics of software engineering 1

Introduction
Software can be defined as a set of programs
and associated documentations.
which includes
A number of separate programs
Configuration files
System documentation
User documentation

What is software engineering ?
Software Engineering can be defined
as the construction of quality software
with a limited budget and a given
deadline in the context of constant
change.

Software engineering (SE) is an intellectual
activity and thus human-intensive
Software is built to meet a certain functional
goal and satisfy certain qualities
Software processes also must meet certain
qualities

Brainstorm about the development of software
engineering
Try to realize the improvements on computer

hardware
Also about the software
But what about the improvements on software

engineering

Fundamental assumptions
of software engineering
Good processes lead to good software

Good processes reduce risk

Software Engineering Concepts: Definitions
Project set of activities to develop a software system
Activity a phase in which related tasks are carried
out
Task effort that uses resources AND produces
WorkProduct
Resources time, equipment, people (participants)
WorkProduct a model, system, or artifact

Software Engineering Concepts
Project
*
Activity
is produced by * consumes
WorkProduct * Task * Resources
System Participant
Model Time
Document Equipment

Software Engineering Activities
Requirements Elicitation
Analysis
Object Design
System Design
Implementation
Validation/testing

Systems, Models, and Views
A model is an abstraction describing system or a subset of
a system
A view depicts selected aspects of a model
A notation is a set of graphical or textual rules for
representing views
How views and models of a single system may overlap

each other?

Why model software?
Software is already an abstraction: why model software?
Software is getting larger, not smaller

5.0 ~ 40 million lines of code
A single programmer cannot manage this amount of code in
its entirety.
Code is often not directly understandable by developers
who did not participate in the development
We need simpler representations for complex systems
Modeling is a mean for dealing with complexity

Concepts and Phenomena
Phenomenon: An object in the world of a domain as you
perceive it, for example:
The lecture you are attending
My black watch
Concept: Describes the common properties of a phenomena,
for example:
Lectures on software engineering
Black watches
A concept is a 3-tuple:
Its Name distinguishes it from other concepts.
Its Purpose are the properties that determine if a phenomenon is a
member of a concept.
Its Members are the phenomena which are part of the concept.

Concepts and Phenomena
Name Purpose Members
Clock A device that

measures time.
Abstraction: Classification of phenomena into concepts

Modeling: Development of abstractions to answer specific
questions about a set of phenomena while ignoring
irrelevant details.

Concepts In Software: Type and Instance
Type:
An abstraction in the context of programming languages
Name: int, Purpose: integral number, Members: 0, -1, 1, 2, -2, . . .
Instance:
Member of a specific type
The type of a variable represents all possible instances the
variable can take.
The relationship between type and instance is similar to
that of concept and phenomenon.
Abstract data type:
Special type whose implementation is hidden from the rest of the
system.

Class
Class:
An abstraction in the context of object-oriented languages
Like an abstract data type, a class encapsulates both state
(variables) and behavior (methods)
Unlike abstract data types, classes can be defined in terms
of other classes using inheritance
Watch
time
date
SetDate(d)
CalculatorWatch
calculatorState
EnterCalcMode()
InputNumber(n)

Object-Oriented Modeling
Application Domain Solution Domain

Application Domain Model System Model
TrafficControl
UML Package MapDisplay
SummaryDisplay
TrafficController FlightPlanDatabase
Aircraft
FlightPlan Airport TrafficControl

Application and Solution Domain
Application Domain (Requirements Analysis):
The environment in which the system is operating
Solution Domain (System Design, Object Design):

The available technologies to build the system

The need of Modeling languages
Notations enable us to articulate complex ideas succinctly
and precisely.
In projects involving many participants, often of different
technical and cultural backgrounds, accuracy and clarity are
critical as the cost of miscommunication increases rapidly.
For a notation to enable accurate communication
It must come with well defined semantics
It must be well studied for representing a given aspect of a
system
It must be well understood among project participants.

When a notation is used by a large number of
participants , there is a little room for misinterpretation
and ambiguity .
Conversely, when many dialects of a notation exists, the
notation users are prone to misunderstanding.
Considering the above issues we will use UML as a
primary notations in our project, given that it has a well
defined semantics, provides a spectrum of notations for
representing different aspects of a system and has been
accepted as a standard notation in the industry.

UML
UML is a notation that resulted from the unification of OMT (Object
Modeling Technique) and OOSE (Object-Oriented Software Engineering).
When using UML the system development focuses on three different
models of the system.
The functional model, represented in UML with use case diagrams,
describes the functionality of the system from the users point of view.
The object model, represented in UML with class diagrams, describes
the structure of a system in terms of objects, attributes, associations, and
operations.
The dynamic model, represented in UML with sequence diagrams, state
chart diagrams , and activity diagrams, describes the internal behavior
of the system. Sequence diagrams describe behavior as a sequence of
messages exchanged among a set of objects, where as state chart
diagrams describe behavior in terms of states of an individual object and
the possible transitions between states.

Use Case diagram
Use cases are used during requirements elicitation and analysis
to represent the functionality of the system.
Use cases focus on the behavior of the system from an external
point of view.
A use case describes a function provided by the system that
yields a visible result for an actor.
An actor describes any entity that interacts with the system
(e.g., a user, another system, the systems physical
environment).
The identification of actors and use cases results in the
definition of the boundary of the system, that is, in
differentiating the tasks accomplished by the system and the
tasks accomplished by its environment.
The actors are outside the boundary of the system, whereas the use cases are
inside the boundary of the system.
UML First Pass: Use Case Diagrams
Package
SimpleWatch
Actor
ReadTime
SetTime
WatchUser WatchRepairPerson
Use case
ChangeBattery
Use case diagrams represent the functionality of the system

from users point of view
Class diagram
We use class diagrams to describe the structure of the
system.
Classes are abstractions that specify the common structure
and behavior of a set of objects.
Objects are instances of classes that are created, modified,
and destroyed during the execution of the system.
Objects have state that includes the values of its attributes
and its relationships with other objects.
Class diagrams describe the system in terms of objects,
classes, attributes, operations, and their associations.

UML First Pass: Class Diagrams
Class
Multiplicity SimpleWatch Association

1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load() now()
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking() Attributes
referesh()
Operations
Class diagrams represent the structure of the system

Sequence diagram
Sequence diagrams are used to formalize the behavior of
the system and to visualize the communication among
objects.
They are useful for identifying additional objects that
participate in the use cases. We call objects involved in a
use case participating objects.
A sequence diagram represents the interactions that take
place among these objects.

UML First Pass: Sequence Diagram
Object
:SimpleWatch :LCDDisplay :Time

:WatchUser
pressButton1() blinkHours()
pressButton1() blinkMinutes()
pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
Message
Activation
Sequence diagrams represent the behavior as interactions

State chart diagram
State chart diagrams describe the behavior of an individual
object as a number of states and transitions between these
states.
A state represents a particular set of values for an object.
Given a state, a transition represents a future state the
object can move to and the conditions associated with the
change of state.

UML First Pass: Statechart Diagrams
Initial state State
Event
button1&2Pressed button2Pressed
Blink Increment
Hours Hours
button1Pressed
Transition
button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
button1Pressed
button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
button1&2Pressed
Final state

Activity diagram
An activity diagram describes a system in terms of
activities.
Activities are states that represent the execution of a
set of operations. The completion of these operations
triggers a transition to another activity.
Activity diagrams are similar to flowchart diagrams in
that they can be used to represent control flow (i.e.,
the order in which operations occur) and data flow
(i.e., the objects that are exchanged among
operations).
Activity diagram

Other UML Notations
UML provide other notations that we will be used during
implementation.
Component diagrams
Deployment diagrams

Assignment -1
Prepare maximum of two page
reading report on software process
paradigms/approaches

Chapter two
Software engineering paradigms and
Challenges

Software process
Software process is a set of activities that leads to the production of a
software product.
Increasingly, new software is developed by extending and modifying
existing systems and by configuring and integrating off-the-shelf
software or system components.
Software processes are complex and , like all intellectual and
creative processes rely on people making decisions and judgments.
Because of the need for judgment and creativity , attempts to
automate software processes have met with limited success.
There is no ideal process that can fit to all types of software system
development.
Processes have evolved to exploit the capabilities of the people in an
organization and the specific characteristics of the system that are
being developed.

What is paradigm/approach
There are a number of definitions set for the term paradigm in various
literatures from different professional perspectives.
The following are some of the definitions:
model, example or pattern
an example that serves as pattern or model
a model of something which explains it or shows how it can be
produced
paradigms are models for solving class of problems (architectural,
interaction, design and so on)
paradigm refers to a set of related concepts which are used by a
person to perceive the real world or a part of it. From S/E and
modeling point of view
a conceptual framework for a scientific discipline; a set of assumptions,
methodologies, and objectives that determine a scientific investigation. Sc.P

The software process paradigms/models
Software process model is an abstract representation of a
software process.
Each process models represents a process from a
particular perspective , and thus provides only partial
information about that process.
The generic models are not definitive descriptions of
software process. Rather they are abstractions of the
process that can be used to explain the different
approaches to software development.
We can think of them as a process frameworks that may be
extended and adapted to create more specific software
engineering processes.
The most widely used generic process models are
The waterfall model: this takes the fundamental

process activities of specification, development,
validation and evolution and represents them as the
separate process phase.
Evolutionary development: this approach
interleaves the activities of specification, development
and validation.
An initial system is rapidly developed from abstract
specification .
Then refined with customer input to produce a system
that satisfies the customers needs.

Component based software engineering: this
approach is based on the existence of a significant
number of reusable components.
These system development process focuses on
integrating these components into a system rather than
developing them from the scratch.
These generic models are not mutually exclusive

and are often used together , specially for large
systems development.

The waterfall model
Is the first published model of the software development process.
The classic waterfall model was introduced in the 1970s by Win
Royce at Lockheed.
It is so named because it can be represented or graphically
modeled as a cascade from establishing requirements, to design ,
to program implementation, to system test, to release to customer.
The principal stages of the model map to fundamental
development activities.
In principle the result of each phase is one or more documents that
are approved and the following phase should not start until the
previous phase finished.

But in practice these stages overlap and feed
information to each other.
The stages in waterfall includes
Requirements definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

Because of the cost of producing and approving
documents, iterations are costly and involve
significant rework.
As a result premature freezing of iterations occur.
This method might work satisfactorily if design
requirements could be perfectly addressed before
flowing down to design, and if the design were perfect
when program implementation began, and if the code
were perfect before testing began, and if testing
guaranteed that no bugs remained in the code before
the users applied it, and of course if the users never
changed their minds about requirements.

Pros and cons of the waterfall model
Advantage
Documentation is produced at each phase and that it
fits with other engineering process models.
Disadvantages
Its inflexible partitioning of the project into distinct
stages.
Requires commitment during requirement elicitation.

Evolutionary approach
Evolutionary development is based on the idea of developing
an initial implementation, exposing this to the user comment
and refining it through many versions until an adequate system
has been developed.
Specification , development and validation activities are
interleaved rather than separate, with rapid feedback across
activities.
As a result these approach is often more effective than the
waterfall approach in producing systems that meets the immediate
needs of customers.

The two fundamental types of evolutionary development are
Exploratory development
The objective of Incremental/Exploratory development is to
deliver a working system to end users. This means that you
should normally start with the user requirements that are best
understood and that have the highest priority. Lower priority and
vague requirements are implemented when and if the users
demand them.
Throwaway prototyping
The objective of throw away prototyping is to validate or derive
the system requirements that are not well understood because you
need to find out more about them. Requirements that are straight
forward may never need to be prototyped.
For large systems it is recommended to combine the best
features of waterfall and evolutionary development
approaches.
Pros and cons of evolutionary development approach
Advantages
Accelerated delivery of customer services: early increments
of the system can deliver high priority functionality so that
customers can get value from the system early in its
development . Customers can see their requirements in
practice and specify changes to be incorporated in the later
releases of the system.
User engagement with the system: users of the system have
to be involved in the incremental development process
because they have to provides feedback to the development
team on delivered increments. Their involvement does not
just mean that the system more likely to meet their
requirements; It also means that the system end users have
made a commitment to it and are likely to want to make it
6/13/2017
work. Basics of software engineering 45
Disadvantages
Management problems: software management structures for
large systems are set up to deal with a software process model
that generates regular deliverables to assess progress.
Contractual problems : the normal contractual model between
the a customer and a software developer is based around a
system specification.
Validation problems
Maintenance problem: continual change tends to corrupt the
structure of any system. This means that anyone apart from the
original developers may face difficulty to understand the
system.

Component based approach
This reuse-oriented approach relies on a large base of reusable
software components and some integrating framework for these
components.
Sometimes these components are systems on their own right or
commercial off the shelf systems that may provide specific
functionality.
CBSE is the process of defining, implementing and integrating
or composing loosely coupled independent components into
systems.
It is driven by
increased size and complexity of systems
Increased demand of more dependable software's
The need of faster delivery.

Essentials of CBSE
Independent components must exist
Component standard that facilitate the integration of components
Middleware that provides software support for component
integration
These generic reuse-oriented approach has the ff stages
Requirement specification
Component analysis
Requirement modification
System design with reuse
Development and integration

Inherent Problems of CBSE
Component trustworthiness
Component certification
Emergent property prediction
Requirement trade-offs
Advantages
Reducing the amount of software to be developed and so
reducing cost and risk.
Faster delivery of the software
Disadvantages
Requirement compromises that leads to a system that do not
meet the real needs of the users.
Control over evolution of the system is lost.
Agile methods
Dissatisfaction with the heavyweight development approach
led a number of software developers in the 1990s to propose
new agile methods.
These method allows the development team to focus on the
software itself rather than on its design and documentation .
Agile methods universally relay on an iterative approach to
software specification, development and delivery, and were
designed primarily to support business application
development where the system requirements usually changed
rapidly during the development process.
They are intended to deliver working software quickly to
customers, who can then propose new and changed
requirements to be included in later iterations of the system.
Principles of agile methods
Customer involvement:- customers should be closely involved
through the development process. their role is provide and prioritize
new system requirements and to evaluate the iterations of the system.
Incremental delivery:- the software is developed in increments with
the customer specifying the requirements to be included in each
increment.
People not process:- the skills of the development team should be
recognized and exploited. Team members should be left to develop
their own ways of working without prescriptive processes.
Embrace change:- expect the system requirements to change, so
design the system to accommodate these changes .
Maintain simplicity:- focus on simplicity in both the software
being developed and in the development process. Wherever
possible , actively work to eliminate complexity from the
system.
Challenges of software engineering
Heterogeneity: Developing techniques for
building software that can cope with
heterogeneous platforms and execution
environments;
Delivery : Developing techniques that lead to
faster delivery of software;
Trust: Developing techniques that demonstrate
that software can be trusted by its users.

Proposal development
Content of proposal document
1. Introduction
1.2. Background
1.3. statement of the problem
1.4. objective
1.5. scope
1.6. significance
2. Methodology and tools
2.1. Methodology
2.2. Tools
2.3. cost analysis
References
Chapter three
Project management

Presentation Outline
Software project management

Management activities
Project planning and Project scheduling
Risk management

Software project management
Software project management is an essential part of software
engineering .
Experienced professional
Plenty of time
Enough budget
These all will leads to success if there would be good management.
Good management can not guarantee project success, however
bad management usually results in project failure.
Bad management may result:
Late delivery
Increased cost
To fail to meet customer requirement
The project managers are responsible :
For planning and scheduling the development
process.
What to do
When to do
How to do
Who will do
What to use
For supervision to ensure that the project is going
on
To the required standard
According to the schedule
Within budget
Software project management is a bit challenging than
managing other types of projects because :
The product is intangible
It is hard to claim a bridge is 90% complete if there is not 90% of the
bridge there.
It is easy to claim that a software project is 90% complete, even if there
are no visible outcomes.
There are no standard software process
The technology changes very quickly.
We dont have much experience on large software projects.
Large software projects are often "bespoke.

Most large software systems are one-off, with experience
gained in one project being of little help in another.

Management activities
Project managers take responsibility for some or all of the
following activities according to the situation.
Proposal writing
Project scheduling and planning
project cost estimation
Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentation

Project planning
The biggest single problem that afflicts software
developing is that of underestimating resources
required for a project.
Developing a realistic project plan is essential to gain
an understanding of the resources required, and how
these should be applied.

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 willBasics
6/13/2017 beofdeveloped.
software engineering 61
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 h/ware and s/ware
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.

Risk management
Involves anticipating risks that might affect the project
schedule or the quality of the software being developed and
taking action to avoid these risks.
The results of risk analysis should be documented in the project
plan along with an analysis of the consequences of a risk
occurring.
There are three categories of risks
Project risks: risks that affect the project schedule or
resources
Product risks: risks that affect the quality or performance of
the software being developed.
Business risks: risks that affect the organization developing
the software
Risk management activities
Risk identification: possible project, product and business
risks are identified.
Risk analysis: consequences of the risks are identified
Risk planning : plan the to address the risks by avoiding
or minimizing its impact on the project
Risk monitoring: the risk is constantly assessed and plans
for risk mitigation are revised as more information about
the risk is gained.

When planning a project, it is critically important to
know what the key risks are, and is possible plan for
them:
Staff turnover
Management change
Hardware unavailability
Requirements change
Specification delays
Size underestimate
Technology change
Product competition

Chapter four
Requirement Engineering
(Requirements Elicitation and Analysis)

Presentation outline
Definitions and types of requirements
Feasibility studies
Requirements elicitation and analysis
Requirements validation
Requirements management

4.1 What is Requirement?
The requirements for a system are the descriptions of the
services provided by the system and its operational
constraints.
These requirements reflect the needs of customers for a system.
The process of finding out, analyzing, documenting and
checking these services and constraints is called requirements
engineering.
There are different levels of abstraction for the term
Requirement.
Some of the problems that arise during the requirements
engineering process are a result of failing to make a clear
separation between the different levels of description.

The different levels of the term requirement abstraction can be
distinguished using the following terms:-
User requirements:- are statements in natural languages
plus diagrams of what services the system is expected to
provide and the constraints under which it must operate.
System requirements:-set out the systems functions,
services and operational constraints in detail.
So it is good to have different levels of system description to
communicate with different kind of readers about the system.

Types of requirements
Why use case diagrams are designed from external
point of view?
Functional requirements
Functional requirements describe the interactions
between the system and its environment
independent of its implementation.
The environment includes the user and any other
external system with which the system interacts.

Nonfunctional requirements
Nonfunctional requirements describe user-visible aspects of
the system that are not directly related with the functional
behavior of the system.
Nonfunctional requirements include quantitative constraints,
such as response time (i.e., how fast the system reacts to
user commands) or accuracy (i.e., how precise are the
systems numerical answers).
Pseudo requirements
Pseudo requirements are requirements imposed by the client
that restrict the implementation of the system.
Typical pseudo requirements are the implementation
language and the platform on which the system is to be
implemented.
4.2 Requirements engineering processes
Requirements engineering aims at defining the requirements of
the system under construction.
Requirements engineering includes two main activities;
requirements elicitation, which results in the specification of
the system that the client understands, and analysis, which
results into an analysis model that the developers can
unambiguously interpret.
The processes used for RE vary widely depending on the
application domain, the people involved and the organization
developing the requirements.

However, the Requirement Engineering process consists four
high-level(generic) sub process.
Feasibility study:- assessing whether the system is useful to the
business
Requirements elicitation and analysis (Requirement
discovery and Requirement specification )
Requirements validation:- Checking that the requirements
actually define the system that the customer wants.
Requirements management:- planning and managing
requirement change

The requirements engineering process

4.2.1 Feasibility studies
A feasibility study decides whether or not the proposed
system is worthwhile.
A short focused study that checks
If the system contributes to organizational objectives;
If the system can be engineered using current technology
and within budget;
If the system can be integrated with other systems that are
used.

4.2.2 Requirement Elicitation and analysis
Sometimes called requirements elicitation or requirements
discovery.
Involves technical staff working with customers to find out
about the application domain, the services that the system
should provide and the systems operational constraints.
May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are
called stakeholders.
Requirements elicitation is about communication among
developers, clients, and users for defining a new system.
Requirements elicitation is the more challenging of the two
because it requires the collaboration of several groups of
participants with different backgrounds.
Requirements elicitation focuses on describing the purpose of
the system.
The client, the developers, and the users identify a problem
area and define a system that addresses the problem. Such a
definition is called a system specification.
The system specification is structured and formalized during
analysis to produce an analysis model.
Both system specification and analysis model represent the
same information. They differ only in the language and
notation they use.

The system specification is written in natural language,
whereas the analysis model is usually expressed in a formal or
semiformal notation.
The system specification supports the communication with the
client and users.
The analysis model supports the communication among
developers.
They are both models of the system in the sense that they
attempt to accurately represent the external aspects of the
system. Given that both models represent the same aspects of
the system.
Requirements elicitation and analysis occur concurrently and
iteratively.

Problems of requirements elicitation and
analysis
Stakeholders dont know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organizational and political factors may influence the
system requirements.
The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.

Elicitation and Analysis Process activities
Requirements discovery
Interacting with stakeholders to discover their
requirements..
The process of gathering information about the proposed
and existing systems and distilling the user and system
requirements from this information.
Sources of information include documentation, system
stakeholders and the specifications of similar systems.
Requirements classification and organization
Groups related requirements and organizes them into
coherent clusters.

Prioritization and negotiation
Prioritizing requirements and resolving requirements
conflicts.
Requirements documentation
Requirements are documented.
Once the requirement specification is done, we need to do the
following activities to have the analysis model.
Identifying actors
Identifying scenarios
Identifying use cases
Refining use cases
Identifying relationships among use cases
Identifying participating objects (Section 4.4.6)
Identifying nonfunctional requirements

Viewpoints(used to cluster needs)
Viewpoints are a way of structuring the requirements to
represent the perspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no
single correct way to analyze system requirements.

Types of viewpoint
Interactor viewpoints
People or other systems that interact directly with the
system. In an ATM, the customers and the account database
are interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselves but who
influence the requirements. In an ATM, management and
security staff are indirect viewpoints.
Domain viewpoints
Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards
for inter-bank communications.

One of the common requirement elicitation mechanism
is Interviewing
In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that they use
and the system to be developed.
There are two types of interview
Closed interviews where a pre-defined set of questions are
answered.
Open interviews where there is no pre-defined agenda and a
range of issues are explored with stakeholders.

Interviews in practice
Normally a mix of closed and open-ended interviewing.
Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact with
the system.
Interviews are not good for understanding domain
requirements
Requirements engineers cannot understand specific domain
terminology;
Some domain knowledge is so familiar that people find it
hard to articulate or think that it isnt worth articulating.

Effective interviewers
Interviewers should be open-minded, willing to listen to
stakeholders and should not have pre-conceived ideas
about the requirements.
They should prompt the interviewee with a question or a
proposal and should not simply expect them to respond to
a question such as what do you want.

4.2.3 Requirements validation
Concerned with demonstrating that the requirements
define the system that the customer really wants.
Requirements error costs are high so validation is very
important
Fixing a requirements error after delivery may cost up to
100 times the cost of fixing an implementation error.

Requirements checking/assuring
Validity. Does the system provide the functions which
best support the customers needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included?
Realism. Can the requirements be implemented given
available budget and technology
Verifiability. Can the requirements be checked?

Requirements validation techniques
Requirements reviews
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.

Requirements reviews(one of the techniques)
Regular reviews should be held while the requirements
definition is being formulated.
Both client and contractor staff should be involved in
reviews.
Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.

Review checks
Verifiability. Is the requirement realistically testable?
Comprehensibility. Is the requirement properly
understood?
Traceability. Is the origin of the requirement clearly
stated?
Adaptability. Can the requirement be changed without a
large impact on other requirements?

4.2.4 Requirements Management
Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
Requirements are inevitably incomplete and inconsistent.
New requirements emerge during the process as business

needs change and a better understanding of the system is
developed;
Different viewpoints have different requirements and these
are often contradictory.

Requirements changes
The priority of requirements from different viewpoints
changes during the development process.
System customers may specify requirements from a
business perspective that conflict with end-user
requirements.
The business and technical environment of the system
changes during its development.

Requirements evolution

Enduring and volatile requirements(from requirement
change perspective)
Enduring requirements. Stable requirements derived
from the core activity of the customer organization. E.g. a
hospital will always have doctors, nurses, etc. May be
derived from domain models
Volatile requirements. Requirements which change
during development or when the system is in use. In a
hospital, requirements derived from health-care policy

Requirements change management
Should apply to all proposed changes to the requirements.
Principal stages
Problem analysis. Discuss requirements problem and
propose change;
Change analysis and costing. Assess effects of change on
other requirements;
Change implementation. Modify requirements document
and other documents to reflect change.

Chapter five
System Design

What is system design
System design is the transformation of the analysis model
into a system design model.
During system design, developers define the design goals
of the project and decompose the system into smaller
subsystems that can be realized by individual teams.
Developers also select strategies for building the system,
such as
The hardware/software platform on which the system will run.
The persistent data management strategy.
The global control flow, the access control policy.
and the handling of boundary conditions.

The result of system design is a model that includes a
clear description of each of these strategies.
In particular, system design includes the ff activities
The definition of design goals
The decomposition of the system into subsystems
The selection of off-the-shelf and legacy components
The mapping of subsystem to hardware
The selection of a persistent data management infrastructure
The selection of an access control policy
The handling of boundary conditions

Deliverables of system design activities
List of design goals, describing the qualities of the system
that developers should optimize.
The definition of design goals is the first step of system
design. It identifies the qualities that our system should
focus on.
Many design goals can be inferred from the nonfunctional
requirements or from the application domain.
Design goals guide the decisions to be made by the
developers especially when trade-offs are needed.

Software architecture, describing the subsystem
decomposition in terms of subsystem responsibilities,
dependencies among subsystems, subsystem mapping to
hardware, and major policy decisions such as control flow,
access control, and data storage
The subsystem decomposition constitutes the bulk of system
design.
Developers divide the system into manageable pieces to deal
with complexity: Each subsystem is assigned to a team and
realized independently.

The subsystem decomposition requires
Hardware/software mapping: What is the hardware configuration
of the system? Which node is responsible for which functionality?
How is communication between nodes realized? Which services
are realized using existing software components? How are these
components encapsulated?
Data management: Which data need to be persistent? Where
should persistent data be stored? How are they accessed?
Access control: Who can access which data? Can access control
change dynamically? How is access control specified and
realized? Access control and security are system-wide issues.
Control flow: How does the system sequence operations? Is the
system event driven? Can it handle more than one user interaction
at a time?
Boundary conditions: How is the system initialized? How is it
shut down? How are exceptional cases detected and handled?

Design phase models
UML deployment diagrams
are used to depict the relationship among run-time
components and hardware nodes.
Components are self-contained entities that provide services
to other components or actors. A Web server, for example, is
a component that provides services to Web browsers. A Web
browser such as Netscape is a component that provides
services to a user.
A distributed system can be composed of many interacting
run-time components.
In UML deployment diagrams, nodes are represented by
boxes containing component icons.
Dependencies between components are represented by
6/13/2017
dashed arrows.
Basics of software engineering 103
System Design Document
1. Introduction
1.1 Purpose of the system
1.2 Design goals
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Current software architecture
3. Proposed software architecture
3.1 Overview
3.2 Subsystem decomposition
3.3 Hardware/software mapping
3.4 Persistent data management
3.5 Access control and security
3.6 Global software control
3.7 Boundary conditions
4. Subsystem services
Glossary
Chapter six
Implementation

Definition of implementation
Activities of implementation phase
Success criteria's During implementation

What is Implementation
Is the process of converting the design details into tangible
product and provision of the product to the end users.
During implementation, developers translate the object
model into source code.
This includes implementing the attributes and methods of
each object and integrating all the objects such that they
function as a single system.
The implementation activity spans the gap between the
detailed object design model and a complete set of source
code files that can be compiled together.
Activities of implementation phase
Construct software components
Constructing the interface based on the design
provided
Mapping the objects into tables
Coding the business rules
Authentication and authorization by mapping the access
control matrix on business process
Assuring the quality by optimizing the most important
characteristics of the application
Following the architectural design to meet the specific needs
of the application.
Verify and test
Assure the system meets the customers requirement
Verify that there are no error during coding of the
business rules
Consistency of the system services
Integration of brainstorming results which are
accepted
Convert data
Convert the existing data to a form compatible with
the newly developed application.

Train users and document the system
Plan and provide training to the users and
administrators
Document the implementation of the architecture.
Update the whole document/if any change/
Install/Deploy the system
Let the customers to start to use the system by providing
it on their workplace.

Steps for successful Deployment/Implementation
Often a smoothly run project gets a black eye because of
problems during implementation. Those problems often crop
up because we dont anticipate and plan for the complexity of
deploying the solution. For example, you might communicate
and plan well for the deployment of a client-server solution,
only to discover during implementation that many of your
workstations aren't powerful enough to handle the load. This is
the type of minor detail that can cause major headaches
Lets look at the major steps associated with
implementation. Note that many of these activities need to
be completed ahead of time. You cannot start planning for
implementation while you are actually implementing.

Prepare the infrastructure. Many solutions are
implemented into a production environment that is
separate and distinct from where the solution was
developed and tested. It is important that the
characteristics of the production environment be
accounted for. This strategy includes a review of
hardware, software, communications, etc. In our example
above, the potential desktop capacity problem would have
been revealed if we had done an evaluation of the
production (or real-world) environment. When you are
ready for implementation, the production infrastructure
needs to be in place.

Coordinate with the organizations involved in
implementation. This may be as simple as
communicating to your client community. However, few
solutions today can be implemented without involving a
number of organizations. For IT solutions, there are
usually one or more operations and infrastructure groups
that need to be communicated to ahead of time. Many of
these groups might actually have a role in getting the
solution successfully deployed. Part of the implementation
work is to coordinate the work of any other groups that
have a role to play. In some cases, developers simply
failed to plan ahead and make sure the infrastructure
groups were prepared to support the implementation. As a
result, the infrastructure groups were forced to drop
everything to make the implementation a success.
Implement training. Many solutions require users to attend
training or more informal coaching sessions. This type of
training could be completed in advance, but the further out the
training is held, the less information will be retained when
implementation rolls around. Training that takes place close to
the time of implementation should be made part of the actual
implementation plan.
Install the production solution. This is the piece everyone
remembers. Your solution needs to be moved from development
to test. If the solution is brand new, this might be finished in a
leisurely and thoughtful manner over a period of time. If this
project involves a major change to a current solution, you may
have a lot less flexibility in terms of when the new solution moves
to production, since the solution might need to be brought down
for a period of time. You have to make sure all of your production
components are implemented successfully, including new
hardware, databases, and program code.
Convert the data. Data conversion, changing data from
one format to another, needs to take place once the
infrastructure and the solution are implemented.
Perform final verification in production. You should
have prepared to test the production solution to ensure
everything is working as you expect. This may involve a
combination of development and client personnel. The
first check is just to make sure everything is up and
appears okay. The second check is to actually push data
around in the solution, to make sure that the solution is
operating as it should. Depending on the type of solution
being implemented, this verification step could be
extensive.

Implement new processes and procedures. Many IT
solutions require changes to be made to business processes
as well. These changes should be implemented at the same
time that the actual solution is deployed.
Monitor the solution. Usually the project team will spend
some period of time monitoring the implemented solution.
If there are problems that come up immediately after
implementation, the project team should address and fix
them.

Chapter seven
Testing

Definition of testing
What, why, who, when of testing
Levels of testing
Techniques/methods of testing

What is software testing
Executing software in a simulated or real environment, using
inputs selected somehow with the aim/goals of :
Detect faults
Establish confidence in software
Evaluate properties of software
Reliability
Performance
Memory Usage
Security
Usability

Software Testing Difficulties
Determining whether or not outputs are correct. because:
We wrote the software to compute the answer.
There is so much output that it is impossible to validate it
all.
There is no (visible) output.
Comparing resulting internal states to expected states.
Determining whether adequate testing has been done.
Determining what you can say about the software when
testing is completed.
Measuring performance characteristics.
Comparing testing strategies.
What, why, who, when, of testing
What is Software Testing?
Process of executing the program with simulated and real world
data, to identify the possible faults
Why testing is necessary?
To assure the quality of the product
Who does the testing?
Developers
Users/clients
External /internal test teams
What has to be tested?
System requirements/functional and nonfunctional/
The coding

When is testing done?
During development
After development
During submission to the client
How often to test?
It depends on the type of the application being developed

Levels of testing
Unit testing
Tests the smallest individually executable code units.
Usually done by programmers. Test cases might be
selected based on code, specification, intuition, etc.
Integration Testing
Tests interactions between two or more units or
components. Usually done by programmers.
Emphasizes interfaces.
System testing
Test the functionality of the entire system.
Usually done by professional testers.
Acceptance testing
The end user runs the system in their environment to
evaluate whether the system meets their criteria.
The outcome determines whether the customer will
accept system. This is often part of a contractual
agreement.
Regression test
Test modified versions of a previously validated system.
Usually done by testers. The goal is to assure that changes
to the system have not introduced errors (caused the
system to regress).

Realities about system testing
Not all problems will be found no matter how
thorough or systematic the testing.
Testing resources (staff, time, tools, labs) are limited.
Specifications are frequently unclear/ambiguous and
changing (and not necessarily complete and up-to-
date).
Systems are almost always too large to permit test
cases to be selected based on code characteristics.

Realities about software testing
Exhaustive testing is not possible.
Testing is creative and difficult.
A major objective of testing is failure
prevention.
Testing must be planned.
Testing should be done by people who are
independent of the developers.

Testing methodologies
Black box testing
No knowledge of internal design or code
required.
Tests are based on requirements and
functionality
White box testing
Knowledge of the internal program design and code
required.
Tests are based on coverage of code
statements, branches, paths,conditions
Incremental testing
A disciplined method of testing the interfaces between unit-
tested programs as well as between system components.
Involves adding unit-testing program module or component
one by one, and testing each result and combination
Thread testing

Chapter One: Basics of Software Engineering

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapter One: Basics of Software Engineering

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter one

Basics of Software engineering

6/13/2017 Basics of software engineering 1

6/13/2017 Basics of software engineering 2

6/13/2017 Basics of software engineering 3

6/13/2017 Basics of software engineering 4

Try to realize the improvements on computer

Also about the software

But what about the improvements on software

6/13/2017 Basics of software engineering 5

Good processes lead to good software

6/13/2017 Basics of software engineering 6

6/13/2017 Basics of software engineering 7

WorkProduct * Task * Resources

6/13/2017 Basics of software engineering 8

6/13/2017 Basics of software engineering 9

How views and models of a single system may overlap

6/13/2017 Basics of software engineering 10

Software is getting larger, not smaller

6/13/2017 Basics of software engineering 11

6/13/2017 Basics of software engineering 12

Clock A device that

Abstraction: Classification of phenomena into concepts

6/13/2017 Basics of software engineering 13

6/13/2017 Basics of software engineering 14

6/13/2017 Basics of software engineering 15

Application Domain Solution Domain

FlightPlan Airport TrafficControl

6/13/2017 Basics of software engineering 16

Solution Domain (System Design, Object Design):

6/13/2017 Basics of software engineering 17

6/13/2017 Basics of software engineering 18

6/13/2017 Basics of software engineering 19

6/13/2017 Basics of software engineering 20

Use case diagrams represent the functionality of the system

6/13/2017 Basics of software engineering 23

Multiplicity SimpleWatch Association

Class diagrams represent the structure of the system

6/13/2017 Basics of software engineering 25

:SimpleWatch :LCDDisplay :Time

Sequence diagrams represent the behavior as interactions

6/13/2017 Basics of software engineering 27

6/13/2017 Basics of software engineering 28

6/13/2017 Basics of software engineering 30

6/13/2017 Basics of software engineering 31

6/13/2017 Basics of software engineering 32

6/13/2017 Basics of software engineering 33

6/13/2017 Basics of software engineering 34

6/13/2017 Basics of software engineering 35

The waterfall model: this takes the fundamental

6/13/2017 Basics of software engineering 37

These generic models are not mutually exclusive

6/13/2017 Basics of software engineering 38

6/13/2017 Basics of software engineering 39

6/13/2017 Basics of software engineering 40

6/13/2017 Basics of software engineering 41

6/13/2017 Basics of software engineering 42

6/13/2017 Basics of software engineering 43

6/13/2017 Basics of software engineering 46

6/13/2017 Basics of software engineering 47

6/13/2017 Basics of software engineering 48

6/13/2017 Basics of software engineering 52