Escolar Documentos
Profissional Documentos
Cultura Documentos
com
Software Engineering:
Definition 1:
Definition 2:
Definition 3:
A discipline whose aim is the production of quality software, software that is delivered
on time, within budget, and that satisfies its requirements.
Software Crisis:
Software crisis is characterized by inability to develop the desired Software Project because
of such problems:
The roots of the software crisis are complexity, expectations, and change. To avoid
software crisis, software engineering principles and process are applied strictly.
It is the simplest model; there is no specification and design phase in this model. In this
model code is built and used; and if there is an error or requires an enhancement then
developer fix it. Cycle of use and fix remain continue till all problems are resolved as shown
in the diagram below. This model can be implemented only when project size is very small.
www.gagnesharora.com
Waterfall Model:
The waterfall model, sometimes called the classic life cycle model suggests a systematic,
sequential approach to software development. This model is named “Waterfall Model”,
because its diagrammatic representation resembles waterfall.
Design phase:
The goal of this phase is to transform the requirements specifications into a structure that is
suitable for implementation in some programming language. Design phase focuses on four
distinct attributes of a program: software architecture, data structure, procedural detail,
interface representations. This work is documented and known as software design description
(SDD) document. The information contained in the SDD should be sufficient to begin the
Implementation phase.
Maintenance Phase:
When software is installed on the customer’s site, maintenance phase starts. The maintenance
is a broad activity which includes: error correction, optimization of the product, software
capabilities enhancement and small modifications in the software with time.
www.gagnesharora.com
Requirement
Analysis and
specifications
Design Phase
Integration and
System testing
Operation and
Maintenance Phase
Waterfall Model
Advantages:
Disadvantages:
• This model expects complete and accurate requirements early in the process, which is
unrealistic.
• In this model, we cannot go back, if the design phase has gone wrong, things can get
very complicated in the implementation phase.
• Risk factor is not included in this model
• The greatest disadvantage of the waterfall model is that until the final stage of the
development cycle is complete, a working model of the software does not lie in the
hands of the client
www.gagnesharora.com
Prototype model:
In this model, a working prototype is developed before developing the actual software. When
prototype is created, it is reviewed by the customer and gives feedback to the developer that
helps to remove uncertainties in the requirements of the software, and an iteration of
refinement is started in order to further clarify requirements as shown in the diagram. After
the finalization of software requirement and specification (SRS) document, the prototype is
discarded and actual system is then developed using the Waterfall approach. Thus, it is used
as an input to waterfall model and produces maintainable and good quality software.
Requirements
Quick Design
Refinement of
requirements as per
Implement suggestion
Customer Evaluation
Not accepted by customer
Accepted by customer
Design
Prototype Model
Operation and
Maintenance Phase
www.gagnesharora.com
The model has the same phases as the waterfall model, but development is done in several
cycles. During the first requirements analysis phase, customers and developers specify as
many requirements as possible and prepare a SRS document. Developers and customer then
prioritize these requirements. And on the basis of these priorities, the complete product is
divided into releases, and developer deliver the product release by release and at every
release, customer has an operational quality product that does a portion of what is required.
With this model, the customer is able to do some useful work even after first release.
Requirments
Release I
Release II
Release III
Spiral Model:
The spiral model, originally proposed by Boehm, is an evolutionary software process model
that couples the iterative nature of prototype with the Risk factor. Project Risks are ignored
in the earlier models which are the main reasons of software project’s failure. By using spiral
model projects are developed through many cycles or phases and each phase is split into four
major sectors or task regions.
OO Methodology is a process to develop software using some well-defined stages and every
stage includes OO data models. The stages are:
System Conception:
System conception deals with the genesis of an application. Initially some person, who
understands both business needs and technology, thinks of an idea for application. Developer
must then explore the idea to understand the needs and devise possible solutions. The purpose
of system conception is to know what need does the proposed system meet and the result of
system justify the cost of building it.
Analysis:
Analysis focuses on preparing models to get a deep understanding of the requirements. the
goal of analysis is to specify what need to be done, not how it is done. It is important to
consider all available inputs, including requirements statements, user interviews, real-world
experience, and artifacts from related systems. The output from analysis is a set of models
that specify a system in a rigorous and complete manner. There are two sub stages to
analysis: domain analysis and application analysis. The domain analysis is a description of
the real-world objects reflected within the system; and the application analysis is addresses
the computer aspects of the application that are visible to users.
Design:
Analysis addresses the what of an application: design addresses the how. Once we have a
thorough understanding of an application from analysis, we are ready to deal with the details
of building a practical and maintainable solution. Design then becomes a process of adding
details and making fine decisions. There are two sub stages to design: system design and
class design.
In System Design, the development team devises a high-level strategy- the system
architecture- for solving the application problem. The system designer must decide what
performance characteristics to optimize and choose a strategy of attacking the problem.
In class Design, details are added to the analysis model in accordance with the system design
strategy. The class designer elaborates both domain and application models.
Implementation:
Implementation is the stage for writing the actual code. Developers map design elements to
programming language and database code.
www.gagnesharora.com
All the above stages include graphical notations called UML (Unified Modeling Language)
and these notations represent data models. These data models are used to describe a system.
Class model:
The class model describes the static structure of the objects in a system and their
relationships. The class model contains class diagrams.
State model:
The state model describes the aspects of an object that change over time. The state diagram is
a graph whose nodes are states and whose arcs are transitions between states caused by
events.
Interaction model:
The interaction model describes how the objects in a system cooperate to achieve broader
results. The interaction model starts with use cases then elaborated with sequence and activity
diagram.
www.gagnesharora.com
• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case
Interview:
After receiving the problem statement from the customer, the first step is to arrange a meeting
with the customer. During the meeting or interview, both the parties would like to understand
each other. Normally specialized developers often called ‘requirement engineers’ interact
with the customer. The objective of conducting an interview is to understand the customer’s
expectations from the software. It will be impossible to interview every stakeholder. Thus
representatives from groups must be selected based on technical expertise, domain
knowledge, credibility and accessibility. During interview questions should be simple and
short.
Brainstorming Sessions:
Brainstorming has become very popular and is being used by most of the companies. It is a
group technique that may be used during requirements elicitation to understand the
requirements. The group discussions promote creative thinking, generate new ideas and
provide platforms to share views. Brainstorming Sessions technique may be carried with
requirement engineers, actual uses, middle level managers or total stake holders.
www.gagnesharora.com
This approach is similar to brainstorming session. The objective of the approach is to bridge
the expectation gap – a difference between what developers think they are supposed to build
and what customers think they are going to get. In order to reduce expectation gap, a team
oriented approach is developed for requirement elicitation and is called Facilitated
Application Specification Technique (FAST). In this technique, meeting is conducted at some
neutral site which is attended both by developers and customers. The meeting is controlled by
a facilitator. Participants also agree not to debate. Each participant presents his or her list of
objectives and services required, and these lists are displayed in the meeting. Discussions are
held on these objectives and services. And after this, combined lists for these topics are
prepared by eliminating redundant entries and adding new ideas. And the same process is
repeated many times and many sessions are held for this; till a consensus (agreement) is
reached.
It is one of the Requirement elicitation techniques and it used to find out the requirements
that enhance the quality of the Software Product. Here, in QFD Prime concern is the
customer satisfaction and emphasizes on the requirements which are valuable to the customer
and to add these valuable requirements to the SRS. To satisfy the customer needs, in QFD
technique, every requirement can be given some value on a scale of 1 to 5 according to their
importance to the customer. And in QFD, it has been suggested that Quality in the software
product is achieved if we fulfill following requirements:
Normal requirement: The objective and goals of the proposed software comes under the
category of Normal requirements and these normal requirements must be fulfilled. e.g. entry
of the marks, calculation of the marks, reports generation are the Normal requirements for the
result management system.
Exciting requirement: Exciting requirements are the requirements which go beyond the
customer’s expectations and prove to very satisfy when present. In Result Management
System, if reports can be generated in various formats; even customers have not demanded,
and this type of requirement is called exciting requirement and enhance the quality of
product.
www.gagnesharora.com
Use case approach is the one of approach of Requirement Elicitation in which interaction
between the user and proposed software system is studied to find out Requirements for the
proposed system. The terms use case, use case scenario, and use case diagram are used
interchangeably but they have different meanings as given below.
Use case scenario: use scenario is the unstructured description of user requirements. e.g. If
we explain the interaction between the user and system as a story description.
Use case: use case is the structured description of user requirements. e.g. if we represent all
the interaction in a template or in a table for requirement elicitation.
Use case diagram: use case diagram are graphically represent of interaction between the user
and system so that requirements can be elicited. Use case diagram for Result Management is
given by:
Marks Entry
Subject Entry
Student info
Entry Student
Data Entry
Operator
Marks view
James Rumbaugh, Grady Booch and Ivar Jacobson are the main contributors in developing
Unified Modeling Language. In every stage in Object Oriented Software Development, there
are Object Oriented Models (Class, State and interaction Model) and the language of these
models is UML.
UML is used to visualize, specify, construct and document the artifacts (Requirements,
Architecture, Design, Source code, Project plans, Tests, Prototype, Releases etc.) of a
software-intensive system. UML is a standard language for writing software blueprints.
The UML is appropriate for modeling systems ranging from enterprise information systems
to distributed Web-based application and even to hard real time embedded systems. It is very
expressive language, addressing all the views needed to develop and then deploy such
systems.
a) Things in UML:
i) Structural things:
Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. Collectively, the structural things
are called classifiers. Structural things are:
• class
• interface
• collaboration
• use case
• active class
• component
www.gagnesharora.com
• artifact
• node
• interaction
• state machine
• activity
i) Dependency
ii) Association
iii) Generalization
iv) Realization
i. Class diagram
ii. Object diagram
iii. Component diagram
iv. Composite structure diagram
v. Use case diagram
vi. Sequence diagram
vii. Communication diagram
viii. State diagram
ix. Activity diagram
x. Deployment diagram
xi. Package diagram
xii. Timing diagram
xiii. Interaction overview diagram
www.gagnesharora.com
The UML’s building blocks cannot simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony with all
its related models.
Models built during the development of a software-intensive system tend to evolve and may
be viewed by many stakeholders in different ways and at different times. For this reason, it is
common for the development team to not only build models that are well-formed, but also to
build models that are
These less-than-well-formed models are unavoidable as the details of a system unfold and
churn during the software development life cycle. The rules of the UML encourage you-but
do not force you-to address the most important analysis, design, and implementation
questions that push such models well-formed over time.
The UML is made simpler by the presence of four common mechanisms that apply
consistently throughout the language:
i. Specification
ii. Adornments
iii. Common division
iv. Extensibility mechanism