Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
What is Software Engineering?
Software Engineering is the systematic approach to the development, operation and maintenance of
software. Software Engineering is concerned with development and maintenance of software products.
The primary goal of software engineering is to provide the quality of software with low cost. Software
Engineering involves project planning, project management, systematic analysis, design, validations and
maintenance activities.
Analysis, design, and development systems, products, or services requires answering several
fundamental questions:





WHAT is a system?
What is included within a system’s boundaries?
WHAT role does a system perform within the User’s organization?
What mission applications does the system perform?
WHAT results-oriented outcomes does the system produce?
These fundamental questions are often difficult to answer. If you are unable to clearly and concisely
delineate WHAT the system is, you have a major challenge. Now add the element of complexity in
bringing groups of people working on same problem to convergence and consensus on the answers. This
is a common problem shared by Users, Acquirers, and System Developers, even within their own
organizations.
Computer software can then be defined as the product that software engineers design and
build. It includes the executable programs, documentation (both electronic and hard copy). In
addition, it may also include data in the form of numbers and text, or even pictorial and
multimedia formats.
“Engineering is the analysis, design, construction, verification and management of technical (or
social) entities.”
System
The term “system” originates from the Greek term syst¯ema, which means to “place together.” Multiple
business and engineering domains have definitions of a system. This text defines a system as:
System An integrated set of interoperable elements, each with explicitly specified and bounded
capabilities, working synergistically to perform value-added processing to enable a User to satisfy
mission-oriented operational needs in a prescribed operating environment with a specified outcome and
probability of success.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
System Components and Characteristics
A big system may be seen as a set of interacting smaller systems known as subsystems or functional
units each of which has its defined tasks. All these work in coordination to achieve the overall objective of
the system. System engineering requires development of a strong foundation in understanding how to
characterize a system, product, or service in terms of its attributes, properties, and performance.
As discussed above, a system is a set of components working together to achieve some goal. The basic
elements of the system may be listed as:





Resources
Procedures
Data/Information
Intermediate Data
Processes
Resources
Every system requires certain resources for the system to exist. Resources can be hardware, software or
liveware. Hardware resources may include the computer, its peripherals, stationery etc. Software
resources would include the programs running on these computers and the liveware would include the
human beings required to operate the system and make it functional.
Thus these resources make an important component of any system. For instance, a Banking system
cannot function without the required stationery like cheque books, pass books etc. such systems also
need computers to maintain their data and trained staff to operate these computers and cater to the
customer requirements.
Procedures
Every system functions under a set of rules that govern the system to accomplish the defined goal of the
system. This set of rules defines the procedures for the system to Chapter 1 - Introduction to Systems
operate. For instance, the Banking systems have their predefined rules for providing interest at different
rates for different types of accounts.
Data/Information
Every system has some predefined goal. For achieving the goal the system requires certain inputs, which
are converted into the required output. The main objective of the System is to produce some useful
output. Output is the outcome of processing. Output can be of any nature e.g. goods, services or
information.
However, the Output must conform to the customer's expectations. Inputs are the elements that enter the
system and produce Output. Input can be of various kinds, like material, information, etc.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Intermediate Data
Various processes process system's Inputs. Before it is transformed into Output, it goes through many
intermediary transformations. Therefore, it is very important to identify the Intermediate Data. For
example, in a college when students register for a new semester, the initial form submitted by student
goes through many departments. Each department adds their validity checks on it.
Finally the form gets transformed and the student gets a slip that states whether the student has been
registered for the requested subjects or not. It helps in building the System in a better way. Intermediate
forms of data occur when there is a lot of processing on the input data. So, intermediate data should be
handled as carefully as other data since the output depends upon it.
Processes
The systems have some processes that make use of the resources to achieve the set goal under the
defined procedures. These processes are the operational element of the system.
For instance in a Banking system there are several processes that are carried out. Consider for example
the processing of a cheque as a process. A cheque passes through several stages before it actually gets
processed and converted. These are some of the processes of the Banking system. All these
components together make a complete functional system.
Systems also exhibit certain features and characteristics, some of which are:





Objective
Standards
Environment
Feedback
Boundaries and interfaces
Objective
Every system has a predefined goal or objective towards which it works. A system cannot exist without a
defined objective. For example an organization would have an objective of earning maximum possible
revenues, for which each department and each individual has to work in coordination.
Standards
It is the acceptable level of performance for any system. Systems should be designed to meet standards.
Standards can be business specific or organization specific.
For example take a sorting problem. There are various sorting algorithms. But each has its own
complexity. So such algorithm should be used that gives most optimum efficiency. So there should be a
standard or rule to use a particular algorithm. It should be seen whether that algorithm is implemented in
the system.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Environment
Every system whether it is natural or man made co-exists with an environment. It is very important for a
system to adapt itself to its environment. Also, for a system to exist it should change according to the
changing environment. For example, we humans live in a particular environment. As we move to other
places, there are changes in the surroundings but our body gradually adapts to the new environment. If it
were not the case, then it would have been very difficult for human to survive for so many thousand
years.
Another example can be Y2K problem for computer systems. Those systems, which are not Y2K
compliant, will not be able to work properly after year 2000. For computer systems to survive it is
important these systems are made Y2K compliant or Y2K ready.
Feed Back
Feedback is an important element of systems. The output of a system needs to be observed and
feedback from the output taken so as to improve the system and make it achieve the laid standards. In fig
1.1, it is shown that a system takes input. It then transforms it into output. Also some feedback can come
from customer (regarding quality) or it can be some intermediate data (the output of one process and
input for the other) that is required to produce final output.
Boundaries and Interfaces
Every system has defined boundaries within which it operates. Beyond these limits the system has to
interact with the other systems. For instance, Personnel system in an organization has its work domain
with defined procedures. If the financial details of an employee are required, the system has to interact
with the Accounting system to get the required details.
Interfaces are another important element through which the system interacts with the outside world.
System interacts with other systems through its interfaces. Users of the systems also interact with it
through interfaces. Therefore, these should be customized to the user needs. These should be as user
friendly as possible.
Classifications of System
From previous section we have a firm knowledge of various system components and its characteristics.
There are various types of system. To have a good understanding of these systems, these can be
categorized in many ways. Some of the categories are open or closed, physical or abstract and natural or
man made information systems, which are explained next.
Classification of systems can be done in many ways.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Physical or Abstract System
Physical systems are tangible entities that we can feel and touch. These may be static or dynamic in
nature. For example, take a computer center. Desks and chairs are the static parts, which assist in the
working of the center. Static parts don't change. The dynamic systems are constantly changing.
Computer systems are dynamic system. Programs, data, and applications can change according to the
user's needs.
Abstract systems are conceptual. These are not physical entities. They may be formulas, representation
or model of a real system.
Open Closed System
Systems interact with their environment to achieve their targets. Things that are not part of the system are
environmental elements for the system. Depending upon the interaction with the environment, systems
can be divided into two categories, open and closed.
Open systems: Systems that interact with their environment. Practically most of the systems are open
systems. An open system has many interfaces with its environment. It can also adapt to changing
environmental conditions. It can receive inputs from, and delivers output to the outside of system. An
information system is an example of this category.
Closed systems:Systems that don't interact with their environment. Closed systems exist in concept only.
Man made Information System
The main purpose of information systems is to manage data for a particular organization. Maintaining
files, producing information and reports are few functions. An information system produces customized
information depending upon the needs of the organization. These are usually formal, informal, and
computer based.
Formal Information Systems: It deals with the flow of information from top management to lower
management. Information flows in the form of memos, instructions, etc. But feedback can be given from
lower authorities to top management.
Informal Information systems: Informal systems are employee based. These are made to solve the day to
day work related problems. Computer-Based Information Systems: This class of systems depends on the
use of computer for managing business applications. These systems are discussed in detail in the next
section.
What is System Analysis and Design?
System development can generally be thought of having two major components: systems analysis and
systems design.In System Analysis more emphasis is given to understanding the details of an existing
system or a proposed one and then deciding whether the proposed system is desirable or not and
whether the existing system needs improvements. Thus, system analysis is the process of investigating a
system, identifying problems, and using the information to recommend improvements to the system.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Stages in building an improved system
The above figuer shows the various stages involved in building an improved system.
System design is the process of planning a new business system or one to replace or complement an
existing system.
Analysis specifies what the system should do. Design states how to accomplish the objective.
After the proposed system is analyzed and designed, the actual implementation of the system occurs.
After implementation, working system is available and it requires timely maintenance.
Role of System Analyst
The system analyst is the person (or persons) who guides through the development of an information
system. In performing these tasks the analyst must always match the information system objectives with
the goals of the organization.
Role of System Analyst differs from organization to organization. Most common responsibilities of System
Analyst are following
1) System analysis
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
It includes system's study in order to get facts about business activity. It is about getting information and
determining requirements. Here the responsibility includes only requirement determination, not the design
of the system.
2) System analysis and design:
Here apart from the analysis work, Analyst is also responsible for the designing of the new
system/application.
3) Systems analysis, design, and programming:
Here Analyst is also required to perform as a programmer, where he actually writes the code to
implement the design of the proposed application.
Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted
person with varied skills required at various stages of the life cycle. In addition to the technical know-how
of the information system development a system analyst should also have the following knowledge.

Business knowledge: As the analyst might have to develop any kind of a business system, he
should be familiar with the general functioning of all kind of businesses.

Interpersonal skills: Such skills are required at various stages of development process for
interacting with the users and extracting the requirements out of them

Problem solving skills: A system analyst should have enough problem solving skills for defining
the alternate solutions to the system and also for the problems occurring at the various stages of the
development process.
Data Collection Techniques
When conducting field studies it is important to obtain accurate and reliable information
about the phenomenon under study. Interviews and questionnaires are the most
straightforward instruments, but the data they produce typically present an incomplete
picture. For example, assume your goal is to assess which programming language
features are most error-prone. A developer can give you general opinions and anecdotal
evidence about this; however you would obtain far more accurate information by
recording and analyzing the developer_s work practicesVtheir efforts at repeatedly
editing and compiling code. Methods such as think-aloud protocols and work diaries are
used for this type of research.
First Degree Techniques:
Direct Involvement of Software Engineers
The first five techniques listed in Table 1 are what we call inquisitive techniques, while
the remaining ones are primarily observational. Each type is appropriate for gathering
different types of information from software engineers.
Inquisitive first-degree techniques allow the experimenter to obtain a general
understanding of the software engineering process. Such techniques are probably the
only way to gauge how enjoyable or motivating certain tools are to use or certain
activities to perform. However, they are often subjective, and additionally do not allow
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
for accurate time measurements.
Interviews and Questionnaires
Both interviews and questionnaires are centered on asking a series of questions.
Questions can be closed-ended, i.e., multiple-choice, or they can be open-ended, i.e.,
conversational responses; it is best to always have at least some open-ended questions
to gain information that cannot be relayed by more specific information seeking
questions. To implement interviews and questionnaires effectively, questions and forms
must be crafted carefully to ensure that the data collected is meaningful (DeVaus,
1996; Foddy, 1994). A poorly worded question results in ambiguous responses that
cannot be interpreted or analyzed. It is highly advisable to pilot test the questions or
forms and then re-design them as you learn which questions unambiguously attack the
pertinent issues.
In order to generate good statistical results from interviews or a questionnaire, a sample
must be chosen that is representative of the population of interest. This requirement is
particularly difficult in software engineering because we lack good demographic information
about the population of developers and maintainers. However, this drawback
should not prevent us from using interviews and questionnaires to conduct field studies,
if we do not intend to perform statistical tests on the data or when the problem or
population is small and well-defined.
Interviews and questionnaires are often conducted in the same series of studies, with
the interviews providing additional information to the answers from the questionnaires.
Advantages. People are familiar with answering questions, either verbally or on paper,
and as a result they tend to be comfortable and familiar with this data collection method.
Participants also enjoy the opportunity to answer questions about their work.
Disadvantages. Interviews and questionnaires rely on respondents_ self-reports of their
behaviors or attitudes. This dependency can bias the results in a number of ways. People
are not perfect recorders of events around them; in particular, they preferentially remember
events that are meaningful to them. For instance in one of our questionnaires,
participants reported that reading documentation was a time-consuming aspect of their
job, but in 40 hours of observation, we hardly saw anyone doing so. 2
If the objective of interviews and questionnaires is to obtain statistics based on the
answers to fixed questions, then issues of sampling arise. Most studies in software
engineering have to use what is called convenience sampling, meaning that we involve
whoever is available and volunteers. This will result in various types of bias, such as
self-selection bias (those most interested in our work may have different characteristics
from the population as a whole). Results must always therefore be reported with an
acknowledgement of potential biases, and other threats to validity. And results should be
used keeping the biases in mind. In most cases, slightly biased data is still much more
useful than a complete lack of data.
Interviews
Face-to-face interviews involve at least one researcher talking, in person, to at least one
respondent at a time. Normally, a fixed list of carefully worded questions forms the basis
of the interview. Depending on the goal of the study, respondents may be encouraged to
elaborate on areas and deviate slightly from the script.
Telephone interviews are the middle ground between face-to-face interviews and
questionnaires. You have the interactivity of an interview at the cost and convenience of
a phone call. Telephone interviews are not as personal as face-to-face interviews, yet
they still provide researchers with opportunities to clarify questions and further probe
interesting responses. Although this technique is popular in opinion polling and market
research, it is little used in empirical software engineering.
Advantages. Interviews are highly interactive. Researchers can clarify questions for
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
respondents and probe unexpected responses. Interviewers can also build rapport with a
respondent to improve the quality of responses.
Disadvantages. Interviews are time and cost inefficient. Contact with the respondent
needs to be scheduled and at least one person, usually the researcher, needs to travel to
the meeting (unless it is conducted by phoneVbut this lessens the rapport that can be
achieved). If the data from interviews consists of audio or video tapes, this needs to be
transcribed and/or coded; careful note-taking may, however, often be an adequate
substitute for audio or video recording.
Examples. Interviews have been used in many studies because they fit well with many
types of inquiries. We have used interviews in longitudinal studies as an aid in
understanding how newcomers adapt to a development team and software system (Sim
and Holt, 1998). We interviewed newcomers once every three weeks over a number of
months to track their progress as maintenance team members. Since this was an
exploratory study, the questions were open-ended.
Questionnaires
Questionnaires are sets of questions administered in a written format. These are the most
common field method because they can be administered quickly and easily. However,
very careful attention needs to be paid to the wording of the questions, the layout of the
forms, and the ordering of the questions in order to ensure valid results. Pfleeger and
Kitchenham have published a six-part series on principles of survey research starting
with (Pfleeger and Kitchenham, 2001). This series gives detailed information about how
to design and implement questionnaires. Punter et al. (2003) further provides information
on conducting web-based surveys in software engineering research.
Advantages. Questionnaires are time and cost effective. Researchers do not need to
schedule sessions with the software engineers to administer them. They can be filled out
when a software engineer has time between tasks, for example, waiting for information
or during compilation. Paper form-based questionnaires can be transported to the respondent
for little more than the cost of postage. Web-based questionnaires cost even
less since the paper forms are eliminated and the data are received in electronic form.
Questionnaires can also easily collect data from a large number of respondents in geographically
diverse locations.
Disadvantages. Since there is no interviewer, ambiguous and poorly-worded questions
are problematic. Even though it is relatively easy for software engineers to fill out questionnaires,
they still must do so on their own and may not find the time. Thus, return rates
Analysis Phase
1. Gather information
2. Define system requirements
a. Functional and nonfunctional
3. Prioritize requirements
4. Prototype for feasibility and discovery
5. Generate and evaluate alternatives
6. Review recommendations with management
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Activities of the Analysis Phase and Their Key Questions
System Requirements
 New system capabilities and constraints
 Functional requirements
o Activities system must perform (use cases)
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
o Based on procedures and business functions
o Documented in analysis models
 Nonfunctional requirements
o Technical environment or performance objectives
o Usability, reliability, and security requirements
Stakeholders—The Source of System Requirements





People with interest in successful system implementation
Three primary groups of stakeholders
o Users (use system)
o Clients (pay for and own system)
o Technical staff (ensure system operation)
Every type of stakeholder is identified by analyst
Horizontal user roles – information flow across departments
Vertical user roles – information needs of clerical staff, middle management, and senior
executives
o Business users perform day-to-day operations
o Information users need current information
o Management users need summary information
o Executive users need strategic information
o External users may have access to system
Techniques for Information Gathering

Analysis phase done to understand business functions and develop system requirements

Original structured approach

o
Create model of existing system
o
Derive requirements from existing system model
Current approach
o

Identify logical requirements for new system
Balance the review of current business functions with new system requirements
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Relationship Between Information Gathering and Model Building
Themes for Information-Gathering Questions
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Characteristics for Successful Requirements Determination





Question everything
Be impartial
Assume anything is possible
Pay attention to details
Reframe
Sampling
Sampling is the process of systematically selecting representative
elements of a population. We use sampling to make assumptions
of the population as a whole.
We sample to:




Contain costs
Speed up data gathering
Improve effectiveness
Reduce bias
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Sampling Design
To design a good sample, analysts need to:




Determine the data to be collected
Determine the population to be sampled
Choose the type of sample
Decide on the sample size (not covered)
Fact-Finding Methods







Review existing reports, forms, and procedure descriptions
Interview and discuss processes with users
Observe and document business processes
Build prototypes
Distribute and collect questionnaires
Conduct joint application design (JAD) sessions
Research vendor solutions
Review Existing Reports, Forms, and Procedure Descriptions
 Source: External industry-wide professional organizations and
trade publications
 Source: Existing business documents and procedure
descriptions within organization
o Identify business rules, discrepancies, and redundancies
o Be cautious of outdated material
o Obtain preliminary understanding of processes
o Use as guidelines/visual cues to guide interviews
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Conduct Interviews and Discussions with Users
o Effective way to understand business functions and rules
o Time consuming and resource expensive
o May require multiple sessions to
o Meet all users
o Understand all processing requirements
o Can meet with individuals or groups of users
o List of detailed questions prepared
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Interviewing
o
o
o
o
Planning the Interview
Conducting the Interview
Writing the Interview Report
Join Application Design (JAD)
Question Types – Open-Ended Questions
Benefits
o
o
o
o
o
o
o
o
Interviewee at ease
Use interviewee vocabulary
Detail
Generate new questions
More interesting for interviewee
More spontaneity
Phrasing is easier for interviewee
Could use them when not prepared
Drawbacks
o
o
o
o
o
May result in too much detail
Possibly lose control of interview
Response may take too much time
Appear unprepared
Appear that objectives are lacking
Question Types – Closed-Ended Questions Benefits
o Save time
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
o
o
o
o
o
Easy to compare interviews
Getting to the point
Control over interview
Cover lots of ground
Getting only relevant data
Drawbacks
o
o
o
o
Boring to interviewee
Lack of detail
Miss main ideas
Fail to build rapport with interviewee
Conducting the Interview
o
o
o
o
o
o
o
o
o
Arrive early
Shake hands
Inform interviewee how you will work (note taking, recorder)
Check equipment
Start with open-ended questions to warm-up interview and
get a feeling of attitudes
Cover all questions in 45 min to 1 hour interview
Reflect back to the interview
Ask if something was not covered
Summarize and give feedback
Writing the Interview Report
o Write a report as soon as possibly after the interview
o Note the main points of the interview and your own opinions
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
o Review the report with the respondent at a follow-up
meeting
Systems development life-cycle
A Software Process is a set of related activities that leads to the production of a software product.
There are many different software processors, but all must include 5 activities that are
fundamental to software engineering. 1. Software specification (Requirement Analysis – RA) 2.
Software Design 3. Software Implementation (Coding) 4. Software Validation (Testing) 5.
Software Evolution (Maintenance and further Development)
The phases that are necessary to develop and maintain a software system is called “DATA
STRUCTURE”.

Preliminary Analysis: The objective of phase1 is to conduct a preliminary analysis,
propose alternative solutions, describe costs and benefits and submit a preliminary plan
with recommendations.
Conduct the preliminary analysis: in this step, you need to find out the organization's
objectives and the nature and scope of the problem under study. Even if a problem refers
only to a small segment of the organization itself then you need to find out what the
objectives of the organization itself are. Then you need to see how the problem being
studied fits in with them.
Propose alternative solutions: In digging into the organization's objectives and specific
problems, you may have already covered some solutions. Alternate proposals may come
from interviewing employees, clients , suppliers, and/or consultants. You can also study
what competitors are doing. With this data, you will have three choices: leave the system
as is, improve it, or develop a new system.
Describe the costs and benefits.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615

Systems analysis, requirements definition: Defines project goals into defined functions
and operation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudocode and other documentation.

Development: The real code is written here.

Integration and testing: Brings all the pieces together into a special testing environment,
then checks for errors, bugs and interoperability.

Acceptance, installation, deployment: The final stage of initial development, where the
software is put into production and runs actual business.

Maintenance: What happens during the rest of the software's life: changes, correction,
additions, moves to a different computing platform and more. This is often the longest of
the stages.
Not every project will require that the phases be sequentially executed. However, the phases are
interdependent. Depending upon the size and complexity of the project, phases may be combined
or may overlap
Investigation
The 1st stage of SDLC is the investigation phase. During this stage, business opportunities and problems
are identified, and information technology solutions are discussed. Multiple alternative projects may be
suggested and their feasibility analyzed. Operational feasibility is assessed, and it is determined whether
or not the project fits with the current business environment, and to what degree it addresses business
objects. In addition, an economic feasibility investigation is conducted to judge the costs and benefits of
the project. Technical feasibility must also be analyzed to determine if the available hardware and
software resources are sufficient to meet expected specifications. A legal feasibility study is important to
discover any potential legal ramification. The results of the feasibility study can then be compiled into a
report, along with preliminary specifications. When the investigation stage ends, a decision whether or not
to move forward with the project should be made. If it is decided to move ahead, a proposal should have
been produced that outlines the general specifications of the project
System analysis
The goal of system analysis is to determine where the problem is in an attempt to fix the system. This
step involves breaking down the system in different pieces to analyze the situation, analyzing project
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
goals, breaking down what needs to be created and attempting to engage users so that definite
requirements can be defined
Design
In systems design the design functions and operations are described in detail, including screen layouts,
business rules, process diagrams and other documentation. The output of this stage will describe the new
system as a collection of modules or subsystems.
The design stage takes as its initial input the requirements identified in the approved requirements
document. For each requirement, a set of one or more design elements will be produced as a result of
interviews, workshops, and/or prototype efforts.
Design elements describe the desired software features in detail, and generally include functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudo-code, and a complete entity-relationship diagram with a full data dictionary. These design
elements are intended to describe the software in sufficient detail that skilled programmers may develop
the software with minimal additional input design.
Testing
The code is tested at various levels in software testing. Unit, system and user acceptance testings are
often performed. This is a grey area as many different opinions exist as to what the stages of testing are
and how much, if any iteration occurs. Iteration is not generally part of the waterfall model, but usually
some occur at this stage. In the testing the whole system is test one by one
Following are the types of testing:












Defect testing the failed scenarios, including defect tracking
Path testing
Data set testing
Unit testing
System testing
Integration testing
Black-box testing
White-box testing
Regression testing
Automation testing
User acceptance testing
Software performance testing
Operations and maintenance
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
The deployment of the system includes changes and enhancements before the decommissioning or
sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change
positions in the organization, new changes will be implemented, which will require system.
Systems analysis and design
The Systems Analysis and Design (SAD) is the process of developing Information Systems (IS) that
effectively use hardware, software, data, processes, and people to support the company’s business
objectives.
Object-oriented analysis
Object-oriented analysis (OOA) is the process of analyzing a task (also known as a problem domain), to
develop a conceptual model that can then be used to complete the task. A typical OOA model would
describe computer software that could be used to satisfy a set of customer-defined requirements. During
the analysis phase of problem-solving, a programmer might consider a written requirements statement, a
formal vision document, or interviews with stakeholders or other interested parties. The task to be
addressed might be divided into several subtasks (or domains), each representing a different business,
technological, or other areas of interest. Each subtask would be analyzed separately. Implementation
constraints, (e.g., concurrency, distribution, persistence, or how the system is to be built) are not
considered during the analysis phase; rather, they are addressed during object-oriented design (OOD).
The conceptual model that results from OOA will typically consist of a set of use cases, one or more UML
class diagrams, and a number of interaction diagrams. It may also include some kind of user interface
mock-up.
Input (sources) for object-oriented design
The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an
output artifact does not need to be completely developed to serve as input of object-oriented design;
analysis and design may occur in parallel, and in practice the results of one activity can feed the other in
a short feedback cycle through an iterative process. Both analysis and design can be performed
incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.
sZDfas Some typical input artifacts for object-oriented design are:

Conceptual model: Conceptual model is the result of object-oriented analysis, it captures
concepts in the problem domain. The conceptual model is explicitly chosen to be independent
of implementation details, such as concurrency or data storage.

Use case: Use case is a description of sequences of events that, taken together, lead to a system
doing something useful. Each use case provides one or more scenarios that convey how the
system should interact with the users called actors to achieve a specific business goal or
function. Use case actors may be end users or other systems. In many circumstances use cases
are further elaborated into use case diagrams. Use case diagrams are used to identify the actor
(users or other systems) and the processes they perform.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615

System Sequence Diagram: System Sequence diagram (SSD) is a picture that shows, for a
particular scenario of a use case, the events that external actors generate, their order, and
possible inter-system events.

User interface documentations (if applicable): Document that shows and describes the look and
feel of the end product's user interface. It is not mandatory to have this, but it helps to visualize
the end-product and therefore helps the designer.

Relational data model (if applicable): A data model is an abstract model that describes how data
is represented and used. If an object database is not used, the relational data model should
usually be created before the design, since the strategy chosen for object-relational mapping is
an output of the OO design process. However, it is possible to develop the relational data model
and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate
the refinement of other artifacts.
Systems development life cycle
Management and control
SPIU phases related to management controls.
The SDLC phases serve as a programmatic guide to project activity and provide a flexible but consistent
way to conduct projects to a depth matching the scope of the project. Each of the SDLC phase objectives
are described in this section with key deliverables, a description of recommended tasks, and a summary
of related control objectives for effective management. It is critical for the project manager to establish
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
and monitor control objectives during each SDLC phase while executing projects. Control objectives help
to provide a clear statement of the desired result or purpose and should be used throughout the entire
SDLC process. Control objectives can be grouped into major categories (domains), and relate to the
SDLC phases as shown in the figure
To manage and control any SDLC initiative, each project will be required to establish some degree of a
Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project.
The WBS and all programmatic material should be kept in the “project description” section of the project
notebook. The WBS format is mostly left to the project manager to establish in a way that best describes
the project work there are many steps to find the java and c++ ways of drama languages
Work breakdown structured organization
Work breakdown structure.[9]
The upper section of the work breakdown structure (WBS) should identify the major phases and
milestones of the project in a summary fashion. In addition, the upper section should provide an overview
of the full scope and timeline of the project and will be part of the initial project description effort leading to
project approval. The middle section of the WBS is based on the seven systems development life cycle
(SDLC) phases as a guide for WBS task development. The WBS elements should consist of milestones
and “tasks” as opposed to “activities” and have a definitive period (usually two weeks or more). Each task
must have a measurable output (e.x. document, decision, or analysis). A WBS task may rely on one or
more activities (e.g. software engineering, systems engineering) and may require close coordination with
other tasks, either internal or external to the project. Any part of the project needing support from
contractors should have a statement of work (SOW) written to include the appropriate tasks from the
SDLC phases. The development of a SOW does not occur during a specific phase of SDLC but is
developed to include the work from the SDLC process that may be conducted by external resources such
as contractors and struct.
Baselines in the SDLC
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Baselines are an important part of the systems development life cycle (SDLC). These baselines are
established after four of the five phases of the SDLC and are critical to the iterative nature of the model
.[10] Each baseline is considered as a milestone in the SDLC.




functional baseline: established after the conceptual design phase.
allocated baseline: established after the preliminary design phase.
product baseline: established after the detail design and development phase.
updated product baseline: established after the production construction phase.
Complementary to SDLC
Complementary software development methods to systems development life cycle (SDLC) are:







Software prototyping
Joint applications development (JAD)
Rapid application development (RAD)
Extreme programming (XP); extension of earlier work in Prototyping and RAD.
Open-source development
End-user development
Object-oriented programming
Comparison of Methodology Approaches (Post, & Anderson 2006)[11]
SDLC
RAD
Open
source
Objects
JAD
Prototyping End User
Control
Formal
MIS
Weak
Standards
Joint
User
Time frame
Long
Short
Medium
Any
Medium
Short
User
Short
–
Users
Many
Few
Few
Varies
Few
One or two One
MIS staff
Many
Few
Hundreds
Split
Few
One or two None
Transaction/DSS Transaction Both
Both
Both
DSS
DSS
DSS
Interface
Minimal
Weak
Windows
Crucial
Crucial
Crucial
Limited
Internal
In Objects
Limited
Weak
None
Minimal
Documentation
Vital
and training
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Integrity and
security
Vital
Vital
Unknown
In Objects
Limited
Weak
Weak
Reusability
Limited
Some
Maybe
Vital
Limited
Weak
None

–
–
–
–
–
–
–
Approaches to developing software:
–
System Software – Controls operating system behavior
–
Real-time Software – Nuclear reactor temperature control
–
Business Software – All applications like Billing, Payroll
–

Engineering and Scientific software – Simulations and statistical packages (uses input
historical data)
Embedded software – Cruise Controls in car


Personal Computer software – MS Office
Artificial Intelligence software – Robot to develop photographic images
–
System software: is a collection of programs written to service other programs (eg :
Compilers,editors, and file management utilities)
Real-time: Software that monitors /analyzes/controls real-world events as they occur is called
real-time . Elements of real time software include a data gathering component that collects and
formats information form as required by the applications
Business software : managing software that access one or more large database containing
business information.
Engineering and scientific software : software which have number crunching algorithms .
Embedded software : Embedded software resides only in the read-only memory and is used for
control products and systems for the consumer and industrial market .
Personal computer Software : word processing ,Spreadsheets , computer graphics ,
entertainment .
Artificial Intelligence software : Software makes use of nonnumerical algorithms to solve
complex problems.that are not amendable to computation or straightforward analysis .
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Software Development Life Cycles
Various software development life cycle models are suitable for specific project related
conditions which include organization, requirements stability, risks, budget, duration of
project. One life cycle model theoretical may suite particular conditions and at the same
time other model may also looks fitting into the requirements but one should consider
trade-off while deciding which model to choose.
A)prescriptive Model
Every Software Engineering organization should describe a unique set of framework activities for
software processes it adopts.
Regardless of the process model that is selected, software engineers have traditionally chosen a generic
process framework with following activities.
Communication
Planning
Modeling
Construction
Deployment
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
1)Waterfall Model or Classic life cycle
Waterfall Model
This is the most common and classic of life cycle models, also
referred to as a linear-sequential life cycle model. It is very
simple to understand and use. In a waterfall model, each phase
must be completed in its entirety before the next phase can
begin. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not to
continue or discard the project. Unlike what I mentioned in the
general model, phases do not overlap in a waterfall model.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
System/information engineering and modeling - Because software is always part of a larger system (or
business), work begins by establishing requirements for all system elements and then allocating some
subset of these requirements to software. System engineering and analysis encompasses requirements
gathering at the system level with a small amount of top-level analysis and design. Information
engineering encompasses requirements gathering at the strategic business level and at the business
area level.
Software requirements analysis - The requirements gathering process is intensified and focused
specifically on software. To understand the nature of the program(s) to be built, the software
engineering (“analyst”) must understand the information domain for the software as well as the
required function, behavior, performance, and interfacing. Requirements for both the system and the
software are documented and reviewed with the customer.
Design - Software design is actually a multi-step process that focuses on four distinct attributes of a
program: data structure, software architecture, interface representations, and procedural (algorithmic)
detail. The design process translates requirements into a representation of the software that can be
assessed for quality before code generation begins.
Testing - Once code has been generated, program testing begins. The testing process focuses on the
logical internals of software, assuring that all statements have been tested, and on the functional
externals-that is, conducting tests to uncover errors and ensure that defined input will produce actual
results that agree with required results.
Maintenance - Change will occur because errors have been encountered, because the software must be
adapted to accommodate changes in its external environment (e.g., a change required because of a new
operating system or peripheral device), or because the customer requires functional or performance
enhancements. Software maintenance reapplies each of the preceding phases to an existing program
rather than a new one.
V-Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a
sequential path of execution of processes. Each phase must be
completed before the next phase begins. Testing is emphasized in
this model more so than the waterfall model though. The testing
procedures are developed early in the life cycle before any coding is
done, during each of the phases preceding implementation.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Requirements begin the life cycle model just like the waterfall
model. Before development is started, a system test plan is
created. The test plan focuses on meeting the functionality
specified in the requirements gathering.
The high-level design phase focuses on system architecture and
design. An integration test plan is created in this phase as well
in order to test the pieces of the software systems ability to work
together.
The low-level design phase is where the actual software components
are designed, and unit tests are created in this phase as well.
The implementation phase is, again, where all coding takes
place. Once coding is complete, the path of execution continues
up the right side of the V where the test plans developed earlier are
now put to use.
Advantages




Simple and easy to use.
Each phase has specific deliverables.
Higher chance of success over the waterfall model due to the development of test plans
early on during the life cycle.
Works well for small projects where requirements are easily understood.
Disadvantages




Very rigid, like the waterfall model.
Little flexibility and adjusting scope is difficult and expensive.
Software is developed during the implementation phase, so no early prototypes of the
software are produced.
Model doesn’t provide a clear path for problems found during testing phases.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
B)Incremental Process Model
Provide limited s/w functionality to user quickly and then refine and expand on that function
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
System/information
engineering
increment 1
design
analysis
increment 2
code
design
analysis
increment 3
code
design
analysis
increment 4
delivery of
1st increment
test
analysis
delivery of
2nd increment
test
code
design
test
code
delivery of
3rd increment
test
delivery of
4th increment
Incremental Model
The incremental model is an intuitive approach to the waterfall
model. Multiple development cycles take place here, making the
life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed iterations. Each iteration passes
through the requirements, design, implementation and testing phases.
A working version of software is produced during the first
iteration, so you have working software early on during the software
life cycle. Subsequent iterations build on the initial software
produced during the first iteration.
Advantages





Generates working software quickly and early during the software life cycle.
More flexible – less costly to change scope and requirements.
Easier to test and debug during a smaller iteration.
Easier to manage risk because risky pieces are identified and handled during its iteration.
Each iteration is an easily managed milestone.
Disadvantages
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Each phase of an iteration is rigid and do not overlap each other.
Problems may arise pertaining to system architecture because not
all requirements are gathered up front for the entire software life
cycle.


1) Incremental Process Model
This combines elements of waterfall model applied in an iterative fashion
e.g word processing s/w developed using the incremental might deliver basic file management editing
and document production function in first increment
More sophisticated editing and document production capabilities in second increment
Spelling and gramer checking in third increment
And advanced page layout capability in fourth increment
PROCESS flow for any increment may use prototyping model.
Incremental
Advantages










Some working functionality can be developed quickly and early in the life cycle.
Results are obtained early and periodically.
Parallel development can be planned.
Progress can be measured.
Less costly to change the scope/requirements.
Testing and debugging during smaller iteration is easy.
Risks are identified and resolved during an iteration; and each iteration is an
easily managed milestone.
Easier to manage risk - High risk part is done first.
With every increment operational product is delivered.
Issues, challenges & risks identified from each increment can be utilized/applied
to the next increment.
Disadvantages

More resources may be required.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615






Although cost of change is lesser but it is not very suitable for changing
requirements.
More management attention is required.
Each phase of an iteration is rigid with no overlaps.
System architecture or design issues may arise because not all requirements are
gathered. up front for the entire life cycle.
Does not allow iterations within an increment.
Defining increments may require definition of the complete system.
2)RAD Model
High speed adoption of waterfall model
Achived using component based construction approach.
Develop fully functional system within shorttime period(e.g. 60 to 90 days)
RAD (Rapid Application Development)
Advantages






Time to deliver is less.
Changing requirements can be accommodated.
Progress can be measured.
Cycle time can be short with use of powerful RAD tools.
Productivity with fewer people in short time.
Use of tools and frameworks.
Disadvantages






Management complexity is more.
Resource requirements may be more.
Suitable for systems that are component based and scalable.
Suitable only when requirements are well known.
Requires user involvement throughout the life cycle.
Suitable for project requiring shorter development times.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
C)Evolutionary Process Model
Software like complex systems evolves over a period of time.
Business and product requirements often change as development proceeds.
1)Prototyping
Customer defines a set of general objectives for software.but does not identify detailed input,processing
or output requirements
Inother case developer is not sure of the efficiency of an algorithm,humen machine
interaction,adaptability of operating system.
2)Spril Model
Spiral Model

The spiral model is similar to the incremental model, with more
emphases placed on risk analysis. The spiral model has four
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615



phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations
(called Spirals in this model). The baseline spiral, starting in
the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals builds on the baseline spiral.
Requirements are gathered during the planning phase. In the
risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the
risk analysis phase.
Software is produced in the engineering phase, along with testing at
the end of the phase. The evaluation phase allows the customer to
evaluate the output of the project to date before the project continues
to the next spiral.
In the spiral model, the angular component represents progress, and the radius of the
spiral represents cost.
Advantages





Changing requirements can be accommodated.
Allows for extensive use of prototypes
Requirements can be captured more accurately.
Users see the system early.
Development can be divided in to smaller parts and more risky parts can be
developed earlier which helps better risk management.
Disadvantages




Management is more complex.
End of project may not be known early.
Not suitable for small or low risk projects (expensive for small projects).
Process is complex

Project’s success is highly dependent on the risk analysis phase.
Can be a costly model to use.


Large number of intermediate stages require excessive documentation.
It provides the potential for RAD of incresingly more complete versions of the s/w.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Software is developed in a series of evolutionary releases.The first circuit around the spiral might beused
to development of a product specification
;subsequent passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the s/w.
WinWin Spiral Model
The Win-Win spiral approach is an extension of the spiral approach. The phase in this approach is same
as the phase in the spiral approach. The only difference is that at the time of the identifying the
requirements, the development team and the customer hold discussion and negotiate on the
requirements that need to be included in the current iteration of the software.
(Additions to the spiral model shown in bold.)
Typical Cycle of the WinWin Spiral

Identify the system or subsystem's key stakeholders.

Identify the stakeholders' win conditions for the system or subsystem.

Negotiate win-win reconciliations of the stakeholders' win conditions.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615

Elaborate the system or subsystem's product and process objectives,
constraints, and alternatives.

Evaluate the alternatives with respect to the objectives and constraints.
Identify an dresolve major sources of product and process risk.

Elaborate the definition of the product and process.

Plan the next cycle, and update the life-cycle plan, including partition of the
system into subsystems to be addressed in parallel cycles. This can include a
plan to terminate the project if it is too risky or infeasible. Secure the
management's commitment to proceed as planned.
D)Specialized Process Model
It takes characteristics of one or more of the conventional model
1)Component-Based Development
Components developed by vendors who offer them as products can be used when software is to be
built.
These components provide targeted functionality with well-defined interfaces that enable the
componebt to be integrated into the software.
This incorporates many of the characteristics of the spiral model.
Evolutionary
Advantages





Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During life cycle software is produced early which facilitates customer evaluation
and feedback.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Disadvantages






Not suitable for smaller projects.
Management complexity is more.
End of project may not be know which is a risk.
Can be costly to use.
Highly skilled resources are required for risk analysis.
Project’s progress is highly dependent upon the risk analysis phase.
Extreme/Agile Development
Advantages








Promotes teamwork and cross training.
Functionality can be developed rapidly and demonstrated.
Resource requirements are minimum.
Suitable for fixed or changing requirements
Delivers early partial working solutions.
Good model for environments that change steadily.
Minimal rules, documentation easily employed.
Enables concurrent development and delivery within an overall planned context.
Disadvantages




Not suitable for handling complex dependencies.
More risk of sustainability, maintainability and extensibility.
An overall plan, an agile leader and agile PM practice is a must without which it
will not work.
Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
Joint Application Development (JAD)
The JAD process is based on four ideas:
1.People who actually work at a job have the best understanding of that job.
2.People who are trained in software development have the best understanding of the
possibilities of that technology.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
3. Software-based information systems and business processes rarely exist in isolation --they
transcend the confines of any single system or office and effect work in related departments.
People working in these related areas have valuable insight on the role of a system within a
larger community.
4.The best information systems are designed when all of these groups work together on a project
as equal partners.
The JAD is usually a 3 to 6 month well-defined project, when systems can be constructed
from commercially available software products that do not require extensive coding or
complex systems integration. For large-scale projects, it is recommended that the project be
organized as an incremental development effort, and that separate JAD's be used for each
increment (Wood and Silver 1995)
Object Oriented Methodology Life Cycle Model
Object-Oriented development requires that object-oriented techniques be used during the analysis,
and implementation of the system. This methodology asks the analyst to determine what the objects
of the system are, how they behave over time or in response to events, and what responsibilities and
relationships an object has to other objects. Object-oriented analysis has the analyst look at all the
objects in a system, their commonalties, difference, and how the system needs to manipulate the
objects
Object Oriented Process
System Analysis
System Design
Object Design
Implementation
The methodology supports and uses three basic Models
Object Model - This model describes the objects in a system and their interrelationships. This
model observes all the objects as static and does not pay any attention to their dynamic nature.
Dynamic Model - This model depicts the dynamic aspects of the system. It portrays the changes
occurring in the states of various objects with the events that might occur in the system.
Functional Model - This model basically describes the data transformations of the system. This
describes the flow of data and the changes that occur to the data throughout the system.
Advantages of Object Oriented Methodology
Object Oriented Methodology closely represents the problem domain. Because of this, it is easier
to produce and understand designs.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
The objects in the system are immune to requirement changes. Therefore, allows changes more
easily.
Object Oriented Methodology designs encourage more re-use. New applications can use the
existing modules, thereby reduces the development cost and cycle time.
Object Oriented Methodology approach is more natural. It provides nice structures for thinking
and abstracting and leads to modular design.
RUP Rational Unified Process
RUP is a iterative development process
RUP is built on the "Six Best Practices"
RUP has four phases:
1.
2.
3.
4.
Inception
Elaboration
Construction
Transition
In each phase nine different workflows are active
RUP structure
The picture shows the workload of each workflow during the project's phases
Why RUP
Risks
Early and continous documentation of the most urgent and the most
probable risks.
Planning
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Follow up
UML
(If used) A common modelling language
Use cases
May be used as test cases, end-user documentation and design description
Glossary
A clearly defined terminology makes everybody in a project aware of the
exact meaning of a term. At every time.
Iteractive development
By doing a piece of work at the time, review it and test its functionality.
Actually saves time because early mistakes can be reveal
Test
Verify the requirements
Best Practices
1.
2.
3.
4.
5.
6.
Develop Iteratively
Manage Requirements
Use Component Architecture
Model Visually
Verify Quality
Control Changes
Causes of failure
1.
2.
3.
4.
5.
Ad hoc Requirement management
Inprecise and non comprehensive communication
Instable architecture
Too complex
Inconsistensis in requirement, design and implementation
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
6.
7.
8.
9.
10.
Insufficient tests
Subjective status judgement
Inablility to manage risks
Uncontrolled changes
Insufficient development automation
Phases and iterations
The software lifecycle is broken into cycles, each cycle working on a new
generation of the product. RUP divides one development cycle in four
consecutive phases:
Inception phase
Elaboration phase
Construction phase
Transition phase
Each phase is concluded with a well-defined milestone - a point in time at
which a certain critical decisions must be made, and therefore key goals must
have been achived.
Iteration
Each phase in RUP can be futher broken down into iterations. An iteration is a
complete development loop resulting in release (internal or external) of an
executable product, a subset of the final product under development, which
grows incrementally from iteration to become the final system.
Manage requirements
The secret of requirement management is to accept that the requirements
change.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
It is a continous process to identify requirements together with the end-user
Requirement management is to:
Elict, organize, and document required functionality and constraints,
Evaluate impact of changes ,
Track and document tradeoffs and decisions.
Requirement management makes it possible to prioritise and track
requirement.
Use Component Architecture
The process focuses on early development and baselining of a robust
executable architecture, prior to committing resources for full-scale
development.
RUP supports component-based software development
Stable, independent modules with clear interfaces isolates software
dependensis.
Model visually
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Visual abstractions help you to
Communicate different aspects of your software;
See how the elements of the system fit together
Make sure the building blocks are consistent with your code
Maintain consistency between a design and its implementation
Promote unambiguous comminucation.
Use cases makes minimal risk for
Hiding of details
No spagetti stuctures
Good design gives quality
Verify Quality
Earliy tests pays off thuosandfold
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
The software from each release (every iteration) is tested and verified
Test cases are created from each use case and each use scenario.
Decisions are made on real test results
High risk areas are tested more thoroughly
Control changes
All change control should go through CM, who should be able to foresee effects
of changes and could be able to plan for them, and manage all artifacts
CM is convener for the CCB (Change Control Board).
CCB is the formal instance for decisions in change requests.
Members of the CCB can be represetatives from the different workflows for
example:
architect ,
test designer,
project manager,
system analyst,
stakeholders
user representant.
Formal change requests makes communication easier in the project.
Everybody must have access to all artifacts
Use Cases
Use cases are a kind of contract between the stakeholder and the developer
Its important to use notions consistent, create a glossary for the whole
project
Use cases are important (if well written) in the test process.
Development process
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Control the order of the activities
Define what artifacts that shall be creates
Specify tasks at individual as well as group level
Establish criterium to monitor and measure progress of the project
Phases
A phase is concluded with a well defined milestone
The Inception and the Elaboration phases are the two most creative parts.
Function and design established all requirements are elicted.
The Construction and the Transition phases are the building parts. Most of
the programming and testing is done. The deployment and delivery.
Inception phase
Inception means start.
The project are proposed.
The business case is established
The scope of the project is delimited.
To accomplish this you must identify all external entities with which the
system will interact (actors) and define the nature of the interaction on a
high-level. This involves identifying all use cases and describing a few
significant ones. The business case includes success criteria, risk assesments,
and estimate of the resources needed, and a phase plan showing dates of major
milestones.
Inception outcome
Vision document
Initial use-case study (10%-20% complete)
Initial project glossary
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Initial business case
Initial risk assessment
Project plan
Business model (if necessary)
One or several prototypes.
Stakeholders decide if or if not commence a full scale project.
Elaboration phase
Elaborate means refinement (careful development)
The purpose of the elaboration phase is to
Analyze the problem domain,
Establish a sound architectural foundation
Develop the project plan
Eliminate the highest risk elements of the project.
You should have a "mile wide and inch deep" view of the system.
Elaboration outcome
Use-case model 80% complete
Supplementary requirements capturing the non functional requirements
and requirements that are not associated with a specific use-case
A Software Architecture Description
An executable architectual prototype.
A revised risk list and revised business case.
A development plan for the whole project, including the coarse-grained
project plan, showing iterations and evaluation criteria for each iteration.
An updated development case specifying the process to be used.
Preliminary user manual (optional).
Construction phase
Construction means to build
During the construction phase all remaining components and application
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
features are developed and integrated into the product, and all features are
thoroughly tested.
Construction outcome
The outcome of the construction phase is a product ready to put in the hands
of the end users.
At minimum, it consists of:
The software product integrated on the adequate platform
The user manual
A description of the current release
This is considered as a "beta"-release
Transition phase
Transition means delivery
The purpose of the transition phase is to transition the software product to the
user community.
Issuse that usually arise:
New releases
Correct some problems
Finish the features that were postpone
"beta-testing" to validate new system against user expectations
The system might run in parallel with a legacy system that it is replacing
conversion of operational databases
training of user maintainers
roll-out the product to markiting, distribution, and sales team
Transition achivements
The primary objectives of the transition phase include:
Achiving user self -supportability
Achiveing stakeholders concurrence that deployment baselines are complete
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
and consistent with the evaluation criteria of the vision
Achieving final produce baseline as rapidly and cost effective as practical
Business modelling
Business modelling are conducted during the inception and the elaboration
phases.
Active workers:
Business process analyst,
Business Designer
Business model reviewer
In business modelling we document business processes using so called usiness
use cases. This assures a common understanding among all stakeholders of
what business process needs to be supported in the organization.
Requirements
The goal of the requirement workflow is to describe what the system should
do and allows the developers and the customer to agree on that description.
To achive this we elict organize and document required functionality and
constraints; tracks and document tradeoffs and decisions.
The system analyst:
Capture a common vocabulary
Develop Requirements Management Plan
Find Actors and Use-Cases
Develop Vision
Elict Stakeholders Requests
The software architect:
Prioritize Use-Cases
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
The requirement reviewer:
Review Requirements
Analysis and Design
The goal of the Analysis and Design workflow is to show how the system will be
realized in the implementation phase.
Architect:
Architectual analysis
Designer
Use-case analysis
Use-case design
Subsystem design
Class design
Implementation
The purposes of the implementation are to code and test the system
Implementor
Implement a component
Fix a defect
perform unit test
Integrator:
Plan system integration
Plan subsystem integration
Integrate subsystem
Integrate system
Code reviewer
Review code
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Test
In the test workflow test cases procedures and other verification methods are
created and described.
Test designer:
Plan test
Design test
Implement test
Evaluate test
Tester
Execute test
Designer
Design test classes and packages
Deployment
To deploy is to pack distribute and install the software at the end-user
Deployment manager:
Develop deployment plan
Manage acceptance test
Define bill of materials
Write release notes
Technical writer
Develop support materials
CM
Configuration and Change Management (CM), monitors and administrates
changes in the projects artifacts so that they are consistent with the
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
requirement.
CM is responsible for release and version control and are convener for the CCB
(Change Control Board)
Configuration Manager:
Set up CM environment
Establish CM policies
Write CM plan
Change Manager:
Establish Change Control Process
Review change request
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Software requirements specification
A software requirements Specification (SRS) – a requirements specification for a software system – is
a complete description of the behavior of a system to be developed and may include a set of use cases
that describe interactions the users will have with the software. In addition it also contains non-functional
requirements. Non-functional requirements impose constraints on the design or implementation (such as
performance engineering requirements, quality standards, or design constraints), and are sometimes
referred to as "ilities".
Software requirements is a sub-field of software engineering that deals with the elicitation, analysis,
specification, and validation of requirements for software.[1]
The software requirement specification document enlists all necessary requirements for project
development. To derive the requirements we need to have clear and thorough understanding of the
products to be developed. This is prepared after detailed communications with project team and the
customer. A general organization of an SRS is as follows



Introduction
o Purpose
o Definitions
o System overview
o References
Overall description
o Product perspective
 System Interfaces
 User Interfaces
 Hardware interfaces
 Software interfaces
 Communication Interfaces
 Memory Constraints
 Operations
 Site Adaption Requirements
o Product functions
o User characteristics
o Constraints, assumptions and dependencies
Specific requirements
o External interface requirements
o Functional requirements
o Performance requirements
o Design constraints
 Standards Compliance
o Logical database requirement
o Software System attributes
 Reliability
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615




o
Availability
Security
Maintainability
Portability
Other requirements
Functional specification
A functional specification (also, functional spec, specs, functional specifications document (FSD),
functional requirements specification, or Program specification, or Product Requirement Document
"PRD") in systems engineering and software development is the documentation that describes the
requested behavior of an engineering system. The documentation typically describes what is needed
by the system user as well as requested properties of inputs and outputs (e.g. of the software
system).
Overview
In systems engineering a specification is a document that clearly and accurately describes the essential
technical requirements for items, materials, or services including the procedures by which it can be
determined that the requirements have been met. Specifications help avoid duplication and
inconsistencies, allow for accurate estimates of necessary work and resources, act as a negotiation and
reference document for engineering changes, provide documentation of configuration, and allow for
consistent communication among those responsible for the eight primary functions of Systems
Engineering. They provide a precise idea of the problem to be solved so that they can efficiently design
the system and estimate the cost of design alternatives. They provide guidance to testers for verification
(qualification) of each technical requirement.[1]
A functional specification does not define the inner workings of the proposed system; it does not include
the specification of how the system function will be implemented. Instead, it focuses on what various
outside agents (people using the program, computer peripherals, or other computers, for example) might
"observe" when interacting with the system. A typical functional specification might state the following:
When the user clicks the OK button, the dialog is closed and the focus is returned to the main
window in the state it was in before this dialog was displayed.
Such a requirement describes an interaction between an external agent (the user) and the software
system. When the user provides input to the system by clicking the OK button, the program responds (or
should respond) by closing the dialog window containing the OK button.
It can be informal, in which case it can be considered as a blueprint or user manual from a developer
point of view, or formal, in which case it has a definite meaning defined in mathematical or programmatic
terms. In practice, most successful specifications are written to understand and fine-tune applications that
were already well-developed, although safety-critical software systems are often carefully specified prior
to application development. Specifications are most important for external interfaces that must remain
stable
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615
Functional and Non-Functional Specifications
In any software developments, the technical team is mainly focusing on the business requirement
document from Customer on how these required functions to be behaved/specify as in system
and requirement engineering so that development team is able to developed, tested and
configured for them as final deliverables to Customers. The term we often used to define these
development scopes is known as “Functional Requirement/Specifications”. However much of
these requirements do not cover on ‘non-functional’ requirements. Non-functional requirement is
to describe/judge the operations of a system and it is important to cover as it will determine the
minimum, possible criteria to sign-off for the deployment. A solution cannot operate successfully
if the infrastructure/configurations are done incorrectly, even though it may meet the functional
requirements.
Some Areas that define as Non-Functional Requirements/Specification:











Accessibility
Performance/Response Time
Usability
Scalability
Compatibility
Reliability
Maintainability
Robustness
Documentation
Effectiveness
Efficiency
The splitting of functional and non-functional modules enable different organization/team
based on their specialization to conduct thorough, detailed setups, configurations and
testings. For example, the system team or may known as Infrastructure team will take care on
the standard setups for the equipment, network design, database/repositories for the usage of
that solution. Configuration team works with the Development team to understand the
configuration parameters required to setup to run the solution. Application testing team takes
charge of the testings of the functions that are designed to perform expected behaviors.
The scopes for functional and non-functional requirements are also to be captured in the
Master Project Plan so that the stakeholders are aware these modules must be reviewed,
covered and achieved at each milestone of the project phase.
Prof. Rajesh Gawali
Email: rajesh_r_gawali@yahoo.com
RAJESH Cell :9422321615