Beruflich Dokumente
Kultur Dokumente
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase in the life
cycle. Requirements are translated into design. Code is produced according to the design which
is called development phase. After coding and development the testing verifies the deliverable of
the implementation phase against requirements.
There are following six phases in every Software development life cycle model:
1. Technical Feasibility: The technical feasibility study compares the level of technology
available in the software development firm and the level of technology required for the
development of the product. Here the level of technology consists of the programming
language, the hardware resources, Other software tools etc. In short it is solution for
Does the company have the technological resources to undertake the project? Are the processes and procedures
2
Q. What is System analysis? Or explain roles of System Analysts?
3. System Analysis:
System analysis is not a preliminary study. It is an in-depth study of end user
information needs that produces functional requirements that are used as the basis for the
design of a new information system.
System involves detailed study of:
The information needs of the organization and end user.
The activities, resources and products of any present information system.
The information system capabilities required to meet your Information needs.
This phase is to collect all the required information for developing the software.
Here the analyst make use of various information gathering tools and technique. After a
careful analysis of the system the analyst come up with an analysis report.
The main objectives of preliminary analysis is to identify the customer's needs, evaluate system
concept for feasibility, perform economic and technical analysis, perform cost benefit analysis
and create system definition that forms the foundation for all subsequent engineering works.
There should be enough expertise available for hardware and software for doing analysis.
3
Understanding how the project will contribute in the organization objectives
Identify sources of requirement
Validation of requirement
Develop and implement requirement management plan
Documentation of business, technical, process and product requirements
Coordination with clients to prioritize requirements and remove and ambiguity
Finalizing acceptance criteria with client and other stakeholders
After the preliminary analysis, the analyst should report the findings to management, with
recommendations outlining the acceptance or rejection of the proposal.
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS. Software designers are use DFD, ERD, structured charts etc.
4
Software Design Levels
Software design yields three levels of results:
Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the single entity-multiple component
concept of architectural design into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design focuses on how the system
along with all of its components can be implemented in forms of modules. It recognizes
modular structure of each sub-system and their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards
modules and their implementations. It defines logical structure of each module and their
interfaces to communicate with other modules.
Q. Explain S/W Design strategies?
Software Design Strategies:
1. Structured Design
Structured design is a conceptualization of problem into several well-organized elements of
solution. It is basically concerned with the solution design. Benefit of structured design is, it
gives better understanding of how the problem is being solved. Structured design also makes it
simpler for designer to concentrate on the problem more accurately.
Structured design is mostly based on divide and conquer strategy where a problem is broken
into several small problems and each small problem is individually solved until the whole
problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good structured
design always follows some rules for communication among multiple modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
5
Another characteristic of functions is that when a program calls a function, the function changes
the state of the program, which sometimes is not acceptable by other modules. Function oriented
design works well where the system state does not matter and program/functions work on input
rather than on a state.
Design Process
The whole system is seen as how data flows in the system by means of data flow
diagram.
DFD depicts how functions changes data and state of entire system.
The entire system is logically broken down into smaller units known as functions on the
basis of their operation in the system.
Each function is then described at large.
3. Object Oriented Design
Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by means
of methods or procedures.
Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding.
Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes. This property of OOD is known as inheritance. This
makes it easier to define specific class and to create generalized classes from specific
ones.
Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the following
steps involved:
A solution design is created from requirement or previous used system and/or system
sequence diagram.
6
Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
Class hierarchy and relation among them is defined.
Application framework is defined.
User interface is part of software and is designed such a way that it is expected to provide the
user insight of the software. UI provides fundamental platform for human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying hardware
and software combination. UI can be hardware or software or a combination of both.
CLI provides a command prompt, the place where the user types the command and feeds to the
system. The user needs to remember the syntax of command and its use. Earlier CLI were not
programmed to handle the user errors effectively.
CLI Elements
A text-based command line interface can have the following elements:
Command Prompt - It is text-based notifier that is mostly shows the context in which
the user is working. It is generated by the software system.
Cursor - It is a small horizontal line or a vertical bar of the height of line, to represent
position of character while typing. Cursor is mostly found in blinking state. It moves as
the user writes or deletes something.
8
Typically, GUI is more resource consuming than that of CLI. With advancing technology, the
programmers and designers create complex GUI designs that work with more efficiency,
accuracy and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system has
following elements such as:
Tabs - If an application allows executing multiple instances of itself, they appear on the
screen as separate windows. Tabbed Document Interface has come up to open multiple
documents in the same window. This interface also helps in viewing preference panel in
application. All modern web-browsers use this feature.
Icon - An icon is small picture representing an associated application. When these icons
are clicked or double clicked, the application window is opened. Icon displays
application and programs installed on a system in the form of small pictures.
9
Cursor - Interacting devices such as mouse, touch pad, digital pen are represented in
GUI as cursors. On screen cursor follows the instructions from hardware in almost real-
time. Cursors are also named pointers in GUI systems. They are used to select menus,
windows and other application features.
5. System Implementation:
Implementation is the stage where theory is converted into practical. The implementation is a
vital step in ensuring the success of new systems. Even a well designed system can fail if it is not
properly implemented.
Structured programming states how the program shall be coded. Structured programming uses
three main concepts:
Top-down analysis - A software is always made to perform some rational work. This
rational work is known as problem in the software parlance. Thus it is very important
that we understand how to solve the problem. Under top-down analysis, the problem is
broken down into small pieces where each one has some significance. Each problem is
individually solved and steps are clearly stated about how to solve the problem.
Modular Programming - While programming, the code is broken down into smaller
group of instructions. These groups are known as modules, subprograms or subroutines.
Modular programming based on the understanding of top-down analysis.
10
Structured Coding - In reference with top-down analysis, structured coding sub-divides
the modules into further smaller units of code in the order of their execution.
Functional Programming
Functional programming is style of programming language, which uses the concepts of
mathematical functions. A function in mathematics should always produce the same result on
receiving the same argument. In procedural languages, the flow of the program runs through
procedures, i.e. the control of program is transferred to the called procedure. While control flow
is transferring from one procedure to another, the program changes its state.
First class and High-order functions - These functions have capability to accept
another function as argument or they return other functions as results.
Pure functions - These functions do not include destructive updates, that is, they do not
affect any I/O or memory and if they are not in use, they can easily be removed without
hampering the rest of the program.
Programming style
Programming style is set of coding rules followed by all the programmers to write the code.
When multiple programmers work on the same software project, they frequently need to work
with the program code written by some other developer. This becomes tedious or at times
impossible, if all developers do not follow some standard programming style to code the
program.
An appropriate programming style includes using function and variable names relevant to the
target task, commenting code for the convenience of reader and overall presentation of code.
This makes the program code readable and understandable by all, which in turn makes
debugging and error solving easier. Also, proper coding style helps ease the documentation and
updation.
Coding Guidelines
Practice of coding style varies with organizations, operating systems and language of coding
itself.
11
The following coding elements may be defined under coding guidelines of an organization:
Naming conventions - This section defines how to name functions, variables, constants
and global variables.
Indenting - This is the space left at the beginning of line, usually 2-8 whitespace or
single tab.
Operators - Defines the rules of writing mathematical, assignment and logical operators.
For example, assignment operator = should have space before and after it, as in x =
2.
Control Structures - The rules of writing if-then-else, case-switch, while-until and for
control flow statements solely and in nested fashion.
Line length - Defines how many characters should be there in one line, mostly a line is
80 characters long.
Functions - This defines how functions should be declared and invoked, with and
without parameters.
Variables - This mentions how variables of different data types are declared and
defined.
Comments - This is one of the important coding components, as the comments included
in the code describe what the code actually does and all other associated descriptions.
This section also helps creating help documentations for other developers.
Version Management - Every time a new software is issued to the customer, developers
have to maintain version and configuration related documentation. This documentation
needs to be highly accurate and available on time.
12
Target-Host - The software program, which is being developed in the organization,
needs to be designed for host machines at the customers end. But at times, it is
impossible to design software that works on the target machines.
Source of this document can be previously stored data about the software, already
running software at the clients end, clients interview, questionnaires and research.
Generally it is stored in the form of spreadsheet or word processing document with the
high-end software management team.
This documentation works as foundation for the software to be developed and is majorly
used in verification and validation phases. Most test-cases are built directly from
requirement documentation.
These documents work as repository for developers to implement the software. Though
these documents do not give any details on how to code the program, they give all
necessary information that is required for coding and implementation.
There are various automated tools available and some comes with the programming
language itself. For example java comes JavaDoc tool to generate technical
documentation of code.
User documentation - This documentation is different from all the above explained. All
previous documentations are maintained to provide information about the software and
its development process. But user documentation explains how the software product
should work and how it should be used to get the desired results.
1. Degree of Change
The degree of change associated with the project is a major factor that affects the
quality of systems development. The scope can vary from implementing minor changes
to an existing system to major changes involving reengineering. It is very important for
the project team to recognize where they are on this spectrum of change.
Managing Change
Ability to manage change is a critical factor to the success of Information Systems
development. The Development of new information systems will invariably affect
the work environment and habits of users. It is unfortunate to note that, not everyone
adapts easily to these changes. This problem will multiply with the increasing complexity
of systems.
14
Managing change requires the ability to recognize existing or potential problems,
particularly ones that are concerns of users and deal with them before they become a
serious threat to the success of the new or modified system.
1. An Employee may feel that he/she will loose his/her job, power , or influence within
the organization.
2. Some employees may be unwilling to work with computers and computer staff.
3. The staff may believe that the proposed system will create more work than it
eliminates.
4. The staff may be worried that the proposed system will negatively alter the structure of
the organization.
5. The staff may not be willing to learn new procedures or approaches.
6. The staff may believe that other problems are more pressing than those solved by the
proposed system.
7. The staff may be worried that the system is being developed by people unfamiliar with
the way things need to get done.
Coordinating effort from all those who are involved or who have interest in the Information
System being developed, is needed to prevent or deal with these type of problems. One remedy is
simply to talk with all the people concerned and identify their biggest concerns. Subsequently the
management can deal with those concerns and try to eliminate them. Once these immediate
concerns are addressed, people can become part of the project team.
Another key factor that contributes to the success of system development is the quality
of project planning. When the project is bigger, it is more likely that poor planning will
lead to significant problems.
Poor systems development planning can be deadly.
Eg. A company developed navigational software that was partly responsible for an air
plane crash Colombia.
Failures of large system projects are due to the following reasons.
1. Fall behind schedule
2. Exceed budget
3. Do not meet expectations
Proper planning can minimize the likelihood of occurrence of these type of problems.
15
Although the steps of systems development seem straightforward, larger projects can become
complex, requiring hundreds of separate activities. For these systems development efforts,
formal project management methods and tools become essential.
A PERT (Program Evaluation and Review Technique) chart is a graphical network model
that shows a projects activities and the relationships between those activities. It is a formalized
approach to develop a project schedule.
A Gantt chart is a simple horizontal bar chart that shows project tasks against a calendar. Each
bar represents a named project task. It is used for planning, monitoring, and coordinating
projects.
Level 2- Repeatable: At this level, project management processes and practices are
established to track project costs, schedules and functionality. The focus is on project
management. Although a system development process is always followed, it may vary from
project to project. Success or failure is still a function of the skills and experiences of the project
team. However demanding effort is made to repeat earlier project successes. Effective project
management practices lay the foundation for standardized processes in the next level.
Level 4- Managed: In this level, organizations use detailed measures of the system
development process. This will help the organization to manage the process and improve
software and system quality.
Level 5- Optimized: In this level all aspects of the system development process is
continuously monitored and improved.
It is very important to recognize that each level is a prerequisite for the next level.
16
They are tools design to automate many of the tasks required in a systems development. CASE
tools also enforce devotion to the systems development life cycle. Think of CASE tools as
software that is used to design and implement other software.
Q. What is SDLC or SDLC Model? List and explain SDLC models in Brief?
SDLC Models:
SDLC, Software Development Life Cycle is a process used by software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle.
It is also called as Software development process.
The software development life cycle (SDLC) is a framework defining tasks
performed at each step in the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be
the standard that defines all the tasks required for developing and maintaining software.
Q. What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
17
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done
through .SRS. . Software Requirement Specification document which consists of all the product
requirements to be designed and developed during the project life cycle.
Stage 3: Designing the product architecture
SRS is the reference for product architects to come out with the best architecture for the product
to be developed. Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented in a DDS - Design Document
Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity , budget and time constraints , the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any).
The internal design of all the modules of the proposed architecture should be clearly defined with
the minutest of the details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much disturb.
Developers have to follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers etc are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The
programming language is chosen with respect to the type of software being developed.
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However this stage refers to the testing
only stage of the product where products defects are reported, tracked, fixed and retested, until
the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometime product deployment happens in stages as per the organizations. business
strategy. The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements
in the targeting market segment. After the product is released in the market, its maintenance is
done for the existing customer base.
SDLC Models
There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development.
18
Following are the most important and popular SDLC models followed in the industry:
Waterfall Model
Spiral Model
RAD
Q. Explain Waterfall Model in Detail?
1. Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In Waterfall model, typically, the outcome of one
phase acts as the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.
Pros Cons
Simple and easy to understand and No working software is produced until late during the life
use cycle.
Easy to manage due to the strictness High amounts of risk and uncertainty.
of the model . each phase has specific Not a good model for complex and object-oriented
deliverables and a review process. projects.
Phases are processed and completed Poor model for long and ongoing projects.
one at a time. Not suitable for the projects where requirements are at a
Works well for smaller projects where moderate to high risk of changing. So risk and
requirements are very well uncertainty is high with this process model.
understood. It is difficult to measure progress within stages.
Clearly defined stages. Cannot accommodate changing requirements.
Well understood milestones. No working software is produced until late in the life
Easy to arrange tasks. cycle.
Process and results are well Adjusting scope during the life cycle can end a project.
documented. Integration is done as a "big-bang. at the very end, which
doesn't allow identifying any technological or business
bottleneck or challenges early.
20
Q. Explain Spiral Model in Detail?
2. Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.
Identification: This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.
This also includes understanding the system requirements by continuous communication
between the customer and the system analyst. At the end of the spiral the product is deployed in
the identified market.
Design: Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design
in the subsequent spirals.
Construct or Build: Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
customer for feedback.
Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.
Following is a diagrammatic representation of spiral model listing the activities in each phase:
OR
Based on the customer evaluation, software development process enters into the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the software.
Spiral Model Application
21
Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum risk
for the customer as well as the development firms. Following are the typical uses of Spiral
model:
When costs there is a budget constraint and risk evaluation is important.
For medium to high-risk projects.
Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
Customer is not sure of their requirements which is usually the case.
Requirements are complex and need evaluation to get clarity.
New product line which should be released in phases to get enough customer feedback.
Significant changes are expected in the product during the development cycle.
Spiral Model Pros and Cons
The advantage of spiral lifecycle model is that it allows for elements of the product to be added
in when they become available or known. This assures that there is no conflict with previous
requirements and design.
This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity. Another positive aspect is that
the spiral model forces early user involvement in the system development effort.
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in indefinite loop. So the discipline of change and the extent of taking change
requests is very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:
Pros Cons
22
Q. Explain RAD Model in Detail?
3. RAD Model:
What is RAD?
Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
In RAD model the functional modules are developed in parallel as prototypes and are integrated
to make the complete product for faster product delivery.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that the prototypes
developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:
Business Modeling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.
Data Modeling: The information gathered in the Business Modeling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established and
defined in detail in relevance to the business model.
Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for
adding , deleting, retrieving or modifying a data object are given.
Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.
Testing and Turnover:The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow and the
interfaces between all the components need to be thoroughly tested with complete test
coverage. Since most of the programming components have already been tested, it
reduces the risk of any major issues.
23
RAD Model Vs Traditional SDLC
The traditional SDLC follows a rigid process models with high emphasis on requirement
analysis and gathering before the coding starts. It puts a pressure on the customer to sign off the
requirements before the project starts and the customer doesn.t get the feel of the product as there
is no working build available for a long time.
The customer may need some changes after he actually gets to see the software, however the
change process is quite rigid and it may not be feasible to incorporate major changes in the
product in traditional SDLC.
RAD model focuses on iterative and incremental delivery of working models to the customer.
This results in rapid delivery to the customer and customer involvement during the complete
development cycle of product reducing the risk of non conformance with the actual user
requirements.
RAD Model Application
RAD model can be applied successfully to the projects in which clear modularization is possible.
If the project cannot be broken into modules, RAD may fail. Following are the typical scenarios
where RAD can be used:
RAD should be used only when a system can be modularized to be delivered in
incremental manner.
It should be used if there.s high availability of designers for modeling.
It should be used only if the budget permits use of automated code generating tools.
RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
Should be used where the requirements change during the course of the project and
working prototypes are to be presented to customer in small iterations of 2-3 months.
24
RAD works well only if high skilled engineers are available and the customer is also committed
to achieve the targeted prototype in the given time frame. If there is commitment lacking on
either side the model may fail.
Following table lists out the pros and cons of RAD Model:
Pros Cons
25