1.**DESIGN ENGINEERING: Allocation of functional responsibilities to units.

Software Design is the process to transform the user User interfaces Unit states and state changes
requirements into some suitable form, which helps Data and control interaction between units
the programmer in software coding and 2.****Software Design Concepts:
implementation. During the software design phase, Concepts are defined as a principal idea or invention
the design document is produced, based on the that comes into our mind or in thought to
customer requirements as documented in the SRS understand something.
document. The software design concept simply means the idea
Objectives of Software Design: or principle behind the design. It describes how you
1. Correctness: A good design should be correct i.e. it plan to solve the problem of designing software, the
should correctly implement all the functionalities of logic, or thinking behind how you will design
the system. software.
2. Efficiency: A good software design should address It allows the software engineer to create the model of
the resources, time, and cost optimization issues. the system or software or product that is to be
3. Understandability: A good design should be easily developed or built. The software design concept
understandable, for which it should be modular and provides a supporting and essential structure or
all the modules are arranged in layers. model for d
4. Completeness: The design should have all the
components like data structures, modules, and
external interfaces, etc.
SOFTWARE DESIGN PROCESS:
The software design process can be divided into the
following three levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Interface Design: Interface design is the specification
of the interaction between a system and its
environment. this phase proceeds at a high level of
abstraction with respect to the inner workings of the
system i.e, during interface design
Interface design should include the following details: The following points should be considered while
Precise description of events in the environment, designing Software:
or messages from agents to which the system must Abstraction- hide Irrelevant data Abstraction simply
respond. means to hide the details to reduce complexity and
Precise description of the events or messages that increases efficiency or quality. Different levels of
the system must produce. Abstraction are necessary and must be applied at
Architectural Design: Architectural design is the each stage of the design process so that any error
specification of the major components of a system, that is present can be removed to increase the
their responsibilities, properties, interfaces, and the efficiency of the software solution and to refine the
relationships and interactions between them. In software solution.
architectural design, the overall structure of the Modularity- subdivide the system Modularity simply
system is chosen, but the internal details of major means dividing the system or project into smaller
components are ignored. parts to reduce the complexity of the system or
Issues in architectural design includes: project. In the same way, modularity in design
Gross decomposition of the systems into major means subdividing a system into smaller parts so
components. that these parts can be created independently and
Allocation of functional responsibilities to then use these parts in different systems to perform
components. different functions.
Component Interfaces Architecture- design a structure of something
Detailed Design: Design is the specification of the Architecture simply means a technique to design a
internal elements of all major system components, structure of something. Architecture in designing
their properties, relationships, processing, and often software is a concept that focuses on various
their algorithms and the data structures. elements and the data of the structure. These
The detailed design may include: components interact with each other and use the
Decomposition of major system components into data of the structure in architecture.
program units.
Refinement- removes impurities Refinement simply
means to refine something to remove any impurities
if present and increase the quality. Refinement is
very necessary to find out any error if present and
then to reduce it.
Pattern- a repeated form The pattern simply means
a repeated form or design in which the same shape is
repeated several times to form a pattern. The pattern
in the design process means the repetition of a
solution to a common recurring problem within a
certain context.
Information Hiding- hide the information
Information hiding simply means to hide the
2.Data flow architectures:
information so that it cannot be accessed by an This kind of architecture is used when input data
unwanted party. to be transformed into output data through a series
Refactoring- reconstruct something Refactoring
of computational manipulative components.
simply means reconstructing something in such a
The figure represents pipe-and-filter architecture
way that it does not affect the behavior of any other
since it uses both pipe and filter and it has a set of
features. Refactoring in software design means
components called filters connected by pipes.
reconstructing the design to reduce complexity and
Pipes are used to transmit data from one
simplify it without affecting the behavior or its
component to the next.
functions.
Each filter will work independently and is
3.*****Architectural Design: designed to take data input of a certain form and
The software needs the architectural design to produces data output to the next filter of a specified
represents the design of software. IEEE defines form.
architectural design as “the process of defining a 3.Call and Return architectures: It is used to create a
collection of hardware and software components and program that is easy to scale and modify. Many sub-
their interfaces to establish the framework for the styles exist within this category. Two of them are
development of a computer system. The software explained below.
that is built for computer-based systems can exhibit Remote procedure call architecture: This
one of these many architectural styles. components is used to present in a main program or
Each style will describe a system category that sub program architecture distributed among
consists of : multiple computers on a network.
A set of components(eg: a database, computational Main program or Subprogram architectures: The
modules) that will perform a function required by main program structure decomposes into number of
the system. subprograms or function into a control hierarchy.
The set of connectors will help in coordination, Main program contains number of subprograms that
communication, and cooperation between the can invoke other components.
components.
Conditions that how components can be integrated
to form the system.
Taxonomy of Architectural styles:
1.Data centred architectures:
A data store will reside at the center of this
architecture and is accessed frequently by the other
components that update, add, delete or modify the
data present within the store. 4.Object Oriented architecture: The components of a
This data-centered architecture will promote system encapsulate data and the operations that
integrability. This means that the existing must be applied to manipulate the data. The
components can be changed and new client coordination and communication between the
components can be added to the architecture without components are established via the message passing.
the permission or concern of other clients. 5.Layered architecture:
Data can be passed among clients using A number of different layers are defined with each
blackboard mechanism. layer performing a well-defined set of operations.
Each layer will do some operations that becomes
closer to machine instruction set progressively.
Intermediate layers to utility services and
application software functions.
4.******COMPONENT LEVEL DESIGN: Module coupling is categorized into the following
Component level design is the definition and design types.
of components and modules after the architectural 1. No direct coupling: Two modules are said to be ‘no
design phase. Component-level design defines the direct coupled’ if they are independent of each other.
data structures, algorithms, interface characteristics, 2. Data coupling: Two modules are said to be ‘data
and communication mechanisms allocated to each coupled’ if they use parameter list to pass data items
component for the system development. for communication.
According to OMG UML specification component is 3. Stamp coupling: Two modules are said to be
expressed as, “A modular, deployable, and ‘stamp coupled’ if they communicate by passing a
replaceable part of a system that encapsulates data structure that stores additional information
implementation and exposes a set of interfaces.” than what is required to perform their functions.
Component Views • OO View – A component is a set 4. Content coupling: Two modules are said to be
of collaborating classes. • Conventional View – A ‘content coupled’ if one module modifies data of
component is a functional element of a program that some other module or one module is under the
incorporates processing logic, the internal data control of another module or one module branches
structures required to implement the processing into the middle of another module.
logic. *DESIGN PRINCIPLES: The design Cohesion
principles for component level design comprises of Cohesion measures the relative functional strength of
the following: Design by Contract Open-Closed a module. It represents the strength of bond between
Principle Subtype Substitution Depend on the internal elements of the modules.
Abstractions Interface Segregation Various types of cohesion are listed below.
The component-level design can be represented by 1. Functional cohesion: In this, the elements within
using different approaches. One approach is to use a the modules are concerned with the execution of a
programming language while other is to use some single function.
intermediate design notation such as graphical (DFD, 2. Sequential cohesion: In this, the elements within
flowchart, or structure chart) *The modular design the modules are involved in activities in such a way
of the software should exhibit the following sets of that the output from one activity becomes the input
properties. *Provide simple interface: Simple interfaces for the next activity.
decrease the number of interactions. Note that the number 3. Communicational cohesion: In this, the elements
of interactions is taken into account while determining within the modules perform different functions, yet
whether the software performs the desired function. each function references the same input or output
Simple interfaces also provide support for reusability of information.
components which reduces the cost to a greater extent. 4. Procedural cohesion: In this, the elements within
*Ensure information hiding: The benefits of the modules are involved in different and possibly
modularity cannot be achieved merely by unrelated activities.
decomposing a program into several modules; rather 5.******Component-Level Design Views
each module should be designed and developed in There are three main views of component-level
such a way that the information hiding is ensured design:
Modularity has become an accepted approach in 1. The object-oriented view/class based component
every engineering discipline. With the introduction
level design
of modular design, complexity of software design has
2. The conventional view
considerably reduced Functional Independence
Each has its own elements and characteristics. These
Functional independence is the refined form of the
will be discussed in detail here.
design concepts of modularity, abstraction, and
Object-Oriented View
information hiding. Functional independence is
In the object-oriented view, a component contains a
achieved by developing a module in such a way that
set of collaborating classes. As a quick reminder,
it uniquely performs given sets of function without
classes are groups of objects with common
interacting with other parts of the system. The
properties, operations, and relationships to other
software that uses the property of functional
objects and meanings.
independence is easier to develop because its
These include, for example, people, physical things,
functions can be categorized in a systematic manner
or locations. Design classes are classes within the
Coupling
context of the software itself. Analysis and design
Coupling measures the degree of interdependence
classes are mentioned here because the object-
among the modules. Several factors like interface
oriented view explains both types of class to identify
complexity, type of data that pass across the
all their operations and attributes, as well as the
interface, type of communication, number of
interfaces that enable classes to communicate and
interfaces per module, etc
collaborate.
2. Conventional View SE tools provide automated or semi-automated
In the conventional view of component-level design, support for the "Process" and the "Methods".
the component is considered a functional element of Tools are integrated so that information created by
the software that integrates the processing logic and one tool can be used by another
necessary internal data structures to perform its task
1. SOFTWARE MYTHS
Widely held but false view Propagate
misinformation and confusion Three types of myth
Management myth
Customer myth
Practitioner’s myth 3. The Capability Maturity Model
MANAGEMENT MYTHS Myth(1) -The available Integration (CMMI)
standards and procedures for software are enough. CMM was developed by the Software Engineering
Myth(2) -Each organization feel that they have Institute (SEI) at Carnegie Mellon University in
state-of-art software development tools since they 1987.
have latest computer. Myth(3) -Adding more
It is not a software process model. It is a
programmers when the work is behind schedule
can catch up. Myth(4) -Outsourcing the software framework which is used to analyse the approach
project to third party, we can relax and let that and techniques followed by any organization to
party build it. develop a software product.
CUSTOMER MYTH Myth(1) - General statement It also provides guidelines to further enhance the
of objective is enough to begin writing programs, maturity of those software products.
the details can be filled in later. Myth(2) -Software It is based on profound feedback and development
is easy to change because software is flexible.
practices adopted by the most successful
PRACTITIONER’S MYTH Myth(1) -Once the
program is written, the job has been done. Myth(2) organizations worldwide.
-Until the program is running, there is no way of This model describes a strategy that should be
assessing the quality. followed by moving through 5 different levels.
Myth(3) -The only deliverable work product is the Each level of maturity shows a process capability
working program Myth(4) -Software Engineering level. All the levels except level-1 are further
creates voluminous and unnecessary
described by Key Process Areas (KPA’s).
documentation and invariably slows down software
development. 4. REQUIRMENT ENGINEERING
2. Layered Technology The process of establishing the services that the
Divided into 4 layers:- customer requires from a system and the constraints
1. A quality Process:- under which it operates and is developed. The
Any engineering approach must rest on an quality. requirements themselves are the descriptions of the
The "Bed Rock" that supports software Engineering system services and constraints that are generated
is Quality Focus. during the requirements engineering process.
2. Process:- Requirements engineering tasks: -
Foundation for SE is the Process Layer Inception Elicitation Elaboration
SE process is the GLUE that holds all the technology Negotiation Specification Validation
layers together and enables the timely development Requirements Management
of computer software. Inception Task
It forms the base for management control of During inception, the requirements engineer asks a
software project. set of questions to establish…
3. Methods:- • A basic understanding of the problem • The people
SE methods provide the "Technical Questions" for who want a solution • The nature of the solution that
building Software. is desired
• The effectiveness of preliminary communication
Methods contain a broad array of tasks that include
and collaboration between the customer and the
communication requirement analysis, design
developer
modeling, program construction testing and support.
• Through these questions, the requirements
4. Tools:-
engineer needs to… • Identify the stakeholders,
Recognize multiple viewpoints, Work toward to assess the impact of each requirement on project
collaboration (give and take policy), Initiate the cost and delivery time • Using an iterative approach,
communication. requirements are eliminated, combined and/or
Eliciting Task modified so that each party achieves some measure
Eliciting requirements is difficult because of • of satisfaction.
Problems of scope in identifying the boundaries of Validation Task
the system or specifying too much technical detail During validation, the work products produced as a
rather than overall system objectives
result of requirements engineering are assessed for
Problems of understanding what is wanted, what the
quality.
problem domain is, and what the computing
Requirements
environment can handle (Information that is
Is each requirement consistent with the overall
believed to be "obvious" is often omitted) • Problems
objective for the system/product? • Have all
of volatility because the requirements change over
requirements been specified at the proper level?
time.
That is, do some requirements provide a level of
Elicitation may be accomplished through two
technical detail that is inappropriate at this stage? •
activities
Is each requirement unambiguous? • Does each
• Collaborative requirements gathering
requirement have attribution? That is, is a source
• Quality function deployment
(generally, a specific individual) noted for each
Elaboration Task
requirement?
During elaboration, the software engineer takes the
Requirements Management Task
information obtained during inception and
During requirements management, the project team
elicitation and begins to expand and refine it • performs a set of activities to identify, control, and
Elaboration focuses on developing a refined technical track requirements and changes to the requirements
model of software functions, features, and at any time as the project proceeds • Each
constraints requirement is assigned a unique identifier • The
• It is an analysis modelling task requirements are then placed into one or more
• Use cases are developed, Domain classes are traceability tables • These tables may be stored in a
database that relate features, sources, dependencies,
identified along with their attributes and
subsystems, and interfaces to the requirements • A
relationships, State machine diagrams are used to requirements traceability table is also placed at the
capture the life on an object end of the software requirements specification.
• The end result is an analysis model that defines the Requirement Engineering Process
functional, informational, and behavioural model of It is a four-step process, which includes -
the problem. 1. Feasibility Study
Developing Use Cases 2. Requirement Elicitation and Analysis
Step One – Define the set of actors that will be 3. Software Requirement Specification
4. Software Requirement Validation
involved in the story • Actors are people, devices, or
5. Software Requirement Management
other systems that use the system or product within
the context of the function and behaviour that is to
be described • Actors are anything that communicate
with the system or product and that are external to
the system itself.
Step Two – Develop use cases, where each one
answers a set of questions.
Negotiation Task
During negotiation, the software engineer
reconciles the conflicts between what the customer
wants and what can be achieved given limited 5. RISK MANAGEMENT
business resources • Requirements are ranked (i.e.,
prioritized) by the customers, users, and other RISK MANAGEMENT
stakeholders • Risks associated with each Risk analysis and management are actions that help
requirement are identified and analyzed • Rough a software team to understand and manage
guesses of development effort are made and uncertainty. Many problems can plague a software
project. Regardless of outcome, it’s a really good Product-specific risks: can be identified by those
idea to identify the risk, asses its probability of with a clear understanding of technology, the people
occurrence and estimate its impact. and the environment specific for building the
RISK STRATEGIES project.
It is divided into 2 types they are 1.Reactive risk RISK PROJECTION
strategy 2.Proactive risk strategy Attempts to rate each risk in two ways:
REACTIVE RISK STRATEGY: i. Probability that the risk is real.
Monitors the project for likely risks. ii. Consequences of the problems associated with the
Resources are set aside to deal with risks when they risk. There are four risk projection steps intended to
become actual problem. consider risks in a manner that leads to
Software team does nothing about risks until prioritization.
something goes wrong .Then, the team attempts to Estimate a scale that reflects the perceived
correct the problem, this is often called a fire fighting probability of a risk.
mode. Delineate the consequences of the risk.
When team fails to solve the problem,”Crisis Estimate the impact of the risk on project and
management “takes over and the project is in real product.
jeopardy. Asses the overall accuracy of the risk projection.
PROACTIVE RISK STRATEGY: RISK REFINEMENT
Better than reactive risk strategy. During early stages of project planning, a risk may
Begins long before technical work is initiated. be stated quite generally. As time passes and more is
Potential risks are identified; their probability and learned about risk, it may be possible to refine the
impacts are assessed and ranked by importance. risk into a set of more detailed risks each somewhere
Software team establishes a plan for managing risks. easy to monitor and manage.
As all the risks cannot be avoided, the team works One way to do this is to represent the risk in
to develop a contingency plan that will enable it to Condition Transition Consequence format:
respond in a controlled and effective manner. Given that<condition>then there is concern that
((possssiiblly))<consequence>..
Refinement helps to isolate the underlying risks
and lead to easier analysis and response.
RISK MITIGATION
If a software team adopts a proactive approach to
risk, avoidance is best strategy, achieved by
developing a plan for mitigation.
For ex, assume that high staff turnover is noted as a
project risk r1.Based on past history and
management intuition, the likelihood l1 of high
Types of Risks turnover is estimated to be 0.70 and the impact x1 is
Project risk Technical risk Business risk produced as critical. i.e. high turnover will have a
Known risks Predictable risks critical impact on project cost and schedule.
Unpredictable risk To mitigate this risk, you would develop a strategy
RISK IDENTIFICATION for reducing turnover.
RISK MONITORING
Systematic attempt to specify threats to the project
After risk mitigation, risk monitoring activity
plan.
commence.
Predictable and known risks can be avoided and
The project manager monitors the factors that
controlled possibly by identification.
may provide an indication of whether the risk is
There are two types of risks for each categorized
becoming more or less likely.
risk:
e.g. In case of high staff turnover, the general
Generic risks: potential threat to every software
project. attitude of team members based on project pressures
,interpersonal relationships among team members,
potential problems with compensation and benefits,
availability of jobs within the company and outside which the various ISO standards apply are as
the company is monitored follows.
Project manager should also monitor the 1. ISO 9001: This standard applies to the
organizations engaged in design, development,
effectiveness of risk mitigation steps.
production, and servicing of goods. This is the
Project manager should monitor work products standard that applies to most software development
carefully to ensure that each can stand on its own. organizations.
The RMMM Plan
An effective risk strategy must consider three issues: 2. ISO 9002: This standard applies to those
Risk avoidance organizations which do not design products but are
Risk monitoring only involved in the production. Examples of these
Risk management category industries contain steel and car
manufacturing industries that buy the product and
6.)Software Reliability
plants designs from external sources and are engaged
Software Reliability means Operational reliability. It
in only manufacturing those products. Therefore,
is described as the ability of a system or component
ISO 9002 does not apply to software development
to perform its required functions under static
organizations.
conditions for a specific period.
Software reliability is also defined as the probability 3. ISO 9003: This standard applies to organizations
that a software system fulfills its assigned task in a that are involved only in the installation and testing
given environment for a predefined number of input of the products. For example, Gas companies.
cases, assuming that the hardware and the input are 8.)SDLC - Waterfall Model
free of error. The Waterfall Model was the first Process Model to
Software Reliability is an essential connect of be introduced. It is also referred to as a linear-
software quality, composed with functionality, sequential life cycle model. It is very simple to use.
usability, performance, serviceability, capability, In "The Waterfall" approach, the whole process of
installability, maintainability, and documentation. software development is divided into separate
Software Reliability is hard to achieve because the phases. i)Requirement Gathering and analysis
complexity of software turn to be high. While any 2.System Design. 3. implementation 4. Integration
system with a high degree of complexity, containing and Testing 5. Deployment of system 6.
software, will be hard to reach a certain level of Maintainance
reliability, system developers tend to push *******SDLC V-Model: The V-model is a type of
complexity into the software layer, with the speedy SDLC model where process executes in a sequential
growth of system size and ease of doing so by manner in V-shape. It is also known as Verification
upgrading the software. and Validation model. It is based on the association
7.)ISO 9000 Quality Standards of a testing phase for each corresponding
Quality assurance systems are defined as the development stage. Development of each step directly
organizational structure, responsibilities, associated with the testing phase.
procedures, processes, and resources for Verification Validation Design Phase: Testing Phase:
implementing quality management. ******SDLC - Agile Model: Agile SDLC model is a
ISO 9000 describes the quality elements that must be combination of iterative and incremental process
present for a quality assurance system to be models. .
compliant with the standard, but it does not describe Agile Methods break the product into small
how an organization should implement these incremental builds. These builds are provided in
elements. iterations. Each iteration typically lasts from about
ISO 9001:2000 is the quality standard that contains one to three weeks.
20 requirements that must be present in an effective ****SDLC - Spiral Model:Spiral model is one of the
software quality assurance system. most important Software Development Life Cycle
Types of ISO 9000 Quality Standards models, which provides support for Risk Handling.
In its diagrammatic representation, it looks like a
spiral with many loops.
The exact number of loops of the spiral is unknown
and can vary from project to project.
Each loop of the spiral is called a Phase of the
software development process
The ISO 9000 series of standards is based on the *****Software Engineering Practice
assumption that if a proper stage is followed for Practice is a broad array of concepts, principles,
production, then good quality products are bound to methods, and tools that you must consider as
follow automatically. The types of industries to software is planned and developed.
George Polya, in a book written in 1945 (!), describes Analysis models represent the customer requirements
the essence of software engineering practice … by depicting the S/W in three different domains: the
1. Understand the problem (communication and information domain, the functional domain, and the
analysis). behavioral domain.
2. Plan a solution (modeling and software design). Design models represent characteristics of the S/W
*****Communication Practices that help practitioners to construct it effectively: the
Before customer requirements can be analyzed, architecture, the user interface, and component-level
modeled, or specified they must be gathered through detail.
a communication (also called requirement elicitation) Analysis Modeling Principles
activity. The information domain of a problem must be
Effective communication is among the most represented and understood:
challenging activities that confront a S/W engineer. Analysis model uses “DATA FLOW DIAGRAM” to
the following are communication principles and show information domain which includes following
concepts that apply to customer communication: detail input flow into system, output flow in system
Listen: focus on the speaker’s words. Be a polite Represent software functions
listener. Represent software behavior. The behavior of the
Prepare before you communicate: Spend the time to S/W is driven by the interaction with the external
understand the problem before you meet with others environment.
“research”. The analysis task should move from essential
Someone should facilitate the communication activity. information toward implementation detail. Analysis
Have a leader “moderator” to keep the conversation begins by describing the problem from the end-user
moving in a productive direction. perspective.
Face-to-face communication is best. Design Modeling Principles.
Take notes and document decisions. The software design model is the equivalent of an
Stay focused, modularize your discussion. The architect’s plans for a house
facilitator should keep the conversation modular; Design must be traceable to the analysis model
leaving one topic only after it has been resolved. The design model translates this information into an
Draw pictures when things are unclear. architecture.
Negotiation is not a contest or a game. It works best Always consider architecture. S/W architecture is the
when both parties win. skeleton of the system to be built.
******Planning Practices Focus on the design of data as it is as important as a
The planning activity encompasses a set of design. Data design is an essential element of t
management and technical practices that enable the architectural design.
S/W team to define a road map as it travels toward Component-level design should exhibit functional
its strategic goal and tactical objectives. independence. The functionality that is delivered by
the following principles always apply: a component should be cohesive- that is, it should
Understand the project scope. Scope provides the S/W focus on one and only one function.
team with a destination. The design model should be developed iteratively.
Involve the customer (and other stakeholders) in the With each iteration, the designer should strive for
planning activity. S/W engineers must often negotiate greater simplicity.
order of delivery, timelines, and other related issues. ******Construction Practices
Recognize that planning is iterative. A plan must be Construction is defined as being composed of both
adjusted to accommodate changes. coding and testing.
Estimate based on what you know. The intent of Coding Principles and Concepts
estimation is to provide an indication of effort, cost, Preparation Principles: Before writing one line of
and task duration, based on the team’s current code, be sure of:
understanding of the work to be done. 1. Understand the problem you are trying to solve.
Be realistic. Even the best S/W engineers make
2. Understand the basic design principles.
mistakes.
Pick a programming language that meets the needs
Adjust granularity as you plan.
of the S/W to be built and the environment in which
Define how quality will be achieved.
it will operate.
Define how you’ll accommodate changes
Coding Principles: As you begin writing code, be
******Modeling Practices
sure you
The process of developing analysis and design
1. Constrain your algorithm by following structured
models is described in this section.
programming practice.
In S/W Eng. work, two models are created: analysis
2. Select the proper data structure.
models and design models.
3. Understand the software architecture.
4. Keep conditional logic as simple as possible. architectures. The infrastructure encompasses the
5. Create easily tested nested loops. h/w and s/w that are used to support the applications
Validation Principles: After you’ve completed your and data
first coding pass, be sure you *******Product Engineering
1. Conduct a code walkthrough. software engineers participate in all levels of the
2. Perform unit test and correct errors. product engineering process that begins with
3. Refactor the code. requirements engineering. The analysis step maps
Testing Principles requirements into representations of data, function,
Testing is a process of executing a program with and behavior
the intent of finding errors. *****System Modeling:
A good test is one that has a high probability of System Modelling is the process of developing
finding an as-yet undiscovered error. abstract models of a system with model presenting a
A successful test is one that uncovers an as-yet- different view or perspective of that system. or A
undiscovered error. System Model represent aspects of a system and its
*******Deployment Practices environment. or System Modelling is a mean of
Customer Expectations for the software must be representing a world view a detailed view of the
managed. “Don’t promise more than you can system using same kind of Graphical Notation.
deliver.” System modeling has now come to mean representing
A complete delivery package should be assembled a system using some kind of graphical notation,
and tested. which is now almost always based on notations in the
Buggy software should be fixed first, delivered later Unified Modeling Language (UML).
******System Engineering Hierarchy • System modelling helps the analyst to understand
The key to system engineering is a clear the functionality of the system and models are used
understanding of context. For software development to communicate with customers.
this means creating a "world view" and Activity diagrams, which show the activities involved
progressively narrowing its focus until all technical in a process or in data processing . • Use case
detail is known. diagrams, which show the interactions between a
The system eng. Process usually begins with a “world system and its environment.
view.” The entire business or product domain is • Sequence diagrams, which show interactions
examined to ensure that the proper business or between actors and the system and between system
technology context can be established. components.
The world view is refined to focus more fully on a • Class diagrams, which show the object classes in
specific domain of interest. the system and the associations between these classes.
Finally, the analysis, design, and construction of a • State diagrams, which show how the system reacts
targeted system element are initiated. to internal and external events.
******Business Process Engineering 10.) Software Process Framework
The goal of Business Process Engineering (BPE) is to Framework is a Standard way to build and deploy
define architectures that will enable a business to use applications.
information effectively. Software Process Framework is a foundation of
BPE is one process for creating an overall plan for complete software engineering process. Software
implementing the computing architecture. process framework includes all set of umbrella
Three different architectures must be analyzed and activities. It also includes number of framework
designed within the context of business objectives activities that are applicable to all software projects.
and goals: A generic process framework encompasses five
Data architecture activities which are given below one by one:
Application architecture 1. Communication: In this activity, heavy
Technology infrastructure communication with customers and other
The data architecture provides a framework for the stakeholders, requirement gathering is done.
information needs of a business. The building blocks 2. Planning: In this activity, we discuss the technical
of the architecture are the data objects that are used related tasks, work schedule, risks, required
by the business. A relationship indicates how objects resources etc.
are connected to one another.
The application architecture encompasses those 3. Modeling: Modelling is about building
elements of a system that transform objects within representations of things in the ‘real world’.In
the data architecture for some business purpose. modelling activity, a product’s model is created in
The technology infrastructure provides the order to better understanding and requirements.
foundation for the data and application
 Graphical User Interface
Command Line Interface: Command Line Interface
provides a command prompt, where the user types
the command and feeds to the system. The user
needs to remember the syntax of the command and
its use.
Graphical User Interface: Graphical User Interface
provides the simple interactive interface to interact
with the system. GUI can be a combination of both
hardware and software. Using GUI, user interprets
the software.
GOLDEN RULES:
The following are the golden rules stated by Theo
Mandel that must be followed during the design of
the interface.
Place the user in control:
Define the interaction modes in such a way that
4. Construction: In software engineering, does not force the user into unnecessary or undesired
construction is the application of set of procedures actions: The user should be able to easily enter and
that are needed to assemble the product. In this exit the mode with little or no effort.
activity, we generate the code and test the product in Provide for flexible interaction: Different people
order to make better product. will use different interaction mechanisms, some
5. Deployment: In this activity, a complete or non- might use keyboard commands, some might use
complete products or software are represented to the mouse, some might use touch screen, etc, Hence all
customers to evaluate and give feedback. on the basis interaction mechanisms should be provided.
of their feedback we modify the products for supply Reduce the user’s memory load:
better product. Reduce demand on short-term memory: When
Umbrella activities include: users are involved in some complex tasks the demand
Risk management on short-term memory is significant.
Software quality assurance(SQA) USER INTERFACE ANALYSIS AND DESIGN
Software configuration management(SCM) The overall process for analyzing and designing a
Measurement user interface begins with the creation of different
Formal technical reviws(FTR) models of system functionInterface Analysis and
11.)PERFORMING USER INTERFACE DESIGN Design Models: Four different models come into play
User interface is the front-end application view to when a user interface is to be analyzed and designed.
which user interacts in order to use the software. To build an effective user interface, “all design
User can manipulate and control the software as well should begin with an understanding of the intended
as hardware by means of user interface. Today, user users, including profiles of their age, gender, physical
interface is found at almost every place where digital abilities, education, cultural or ethnic background,
technology exists, right from computers, mobile motivation, goals and personality. INTERFACE
phones, cars, music players, airplanes, ships etc. ANALYSIS
User interface is part of software and is designed A key tenet of all software engineering process
such a way that it is expected to provide the user models is: understand the problem before you
insight of the software. UI provides fundamental attempt to design a solution. In the case of user
platform for human-computer interaction. interface design, understanding the problem means
UI can be graphical, text-based, audio-video based, understanding (1) the people (end users) who will
depending upon the underlying hardware and interact with the system through the interface, (2) the
software combination. UI can be hardware or tasks that end users must perform to do their work,
software or a combination of both. (3) the content that is presented as part of the
The software becomes more popular if its user interface, and (4) the environment in which these
interface is: tasks will be conducted.
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