Professional Documents
Culture Documents
The system development life cycle framework provides a sequence of activities for
system
Designers and developers to follow. It consists of a set of steps or phases involved in an
Information system development project.
a. What are the main phases of Software Development Life Cycle?
Briefly explain each of them.
b. What are the types of feasibility studies? Explain.
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.
2.
3.
4.
5.
6.
requirements phase. During this phase unit testing, integration testing, system testing,
acceptance testing are done.
5) Deployment: After successful testing the product is delivered / deployed to the
customer for their use.
6) Maintenance: Once when the customers starts using the developed system then the
actual problems comes up and needs to be solved from time to time. This process
where the care is taken for the developed product is known as maintenance.
b. Feasibility study is an assessment of the practicality of a proposed project. The acronym
TELOS refers to the five areas of feasibility - Technical, Economic, Legal, Operational, and
Scheduling.
Technical feasibility
The technical feasibility assessment is focused on gaining an understanding of the present
technical resources of the organization and their applicability to the expected needs of the
proposed system. It is an evaluation of the hardware and software and how it meets the need
of the proposed system
Economic feasibility
The purpose of the economic feasibility assessment is to determine the positive economic
benefits to the organization that the proposed system will provide. It includes quantification
and identification of all the benefits expected. This assessment typically involves a cost/
benefits analysis.
Operational feasibility
Operational feasibility is a measure of how well a proposed system solves the problems, and
takes advantage of the opportunities identified during scope definition and how it satisfies the
requirements identified in the requirements analysis phase of system development.
Schedule feasibility
A project will fail if it takes too long to be completed before it is useful. Typically this means
estimating how long the system will take to develop, and if it can be completed in a given
time period using some methods like payback period. Schedule feasibility is a measure of
how reasonable the project timetable is. Given our technical expertise, are the project
deadlines reasonable? Some projects are initiated with specific deadlines. It is necessary to
determine whether the deadlines are mandatory or desirable.
2. Several software development approaches have been used since the origin of information
technology, in two main categories. Typically an approach or a combination of approaches
is chosen by management or a development team.
a. Explain any three software process models.
b. Discuss about their advantages and disadvantages.
a.
Waterfall model,incremental model, V-model, iterative model, etc. Each process model
follows a particular life cycle in order to ensure success in process of software development.
1 Waterfall Model
The first published model of the software development process was derived from more
general system engineering processes. It was proposed by Royces in 1970.
Because of the cascading from one phase to another, this model is known as the
waterfall model. The waterfall model is plan driven process- in principle. You must
plan and schedule all of the process activities before starting work on then. And this is
non liner model but involves feedback from one phase to another.
One development stage should be complete before next begins. Example all the requirements
are collected from customer, analysis from completeness and consistency and documented in
a requirements document, then only development team go to design activity.
2 Spiral Model
The spiral model was proposed by Boehm in 1988. The spiral model can describe how
a product develops to forms new versions, and how a version can be incrementally
developed prototype to completed product.
The diagrammatic representation of this model appears like a spiral with many loops.
The exact number of loops of the spiral is not fixed and can vary from project to
project. Each loop of the spiral is called a phase or Iteration of the software process.
3. Incremental model
In incremental model the whole requirement is divided into various builds.
Multiple development cycles take place here, making the life cycle a
multi-waterfall cycle. Cycles are divided up into smaller, more easily
managed modules.
Each module passes through the requirements,
design, implementation and testing phases. A working version of software
is produced during the first module, so you have working software early
on during the software life cycle. Each subsequent release of the module
adds function to the previous release. The process continues till the
complete system is achieved.
Generates working software quickly and early during the software life cycle.
This model is more flexible less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during itd
iteration.
For the developers of a project, the spiral model usually as a complex model to
follow. It is not suitable for development product as outsourced projects because risks
need to be continually assessed and developed.
a.
A functional requirement for a SMAK fruit juice Packet would be ability to contain
fluid without leaking
Some of the more typical functional requirements include:
Business Rules
Transaction corrections, adjustments and cancellations
Administrative functions
6
Authentication
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Historical Data
Legal or Regulatory Requirements
So about Non-Functional Requirements are those, and how are they different?
Simply put, the difference is that non-functional requirements describe how the
system works, while functional requirements describe what the system should do.
The definition for a non-functional requirement is that it essentially specifies how the
system should behave and that it is a constraint upon the systems behavior. One could
also think of non-functional requirements as quality attributes for of a system.
A non-functional requirement for a hard hat might be must not break under pressure
of less than 10,000 PSI
Non-functional requirements cover all the remaining requirements which are not
covered by the functional requirements. They specify criteria that judge the operation
of a system, rather than specific behaviors, for example: Modified data in a database
should be updated for all users accessing it within 2 seconds.
Some typical non-functional requirements are:
Performance for example Response Time, Throughput, Utilization, Static
Volumetric
Scalability
Capacity
Availability
Reliability
Recoverability
Maintainability
Serviceability
Security
Regulatory
Manageability
Environmental
Data Integrity
Usability
Interoperability are the non-functional requirements.
b.
Structured and Unstructured Interviews
7
Questionnaires are much more informal, and they are good tools to gather
requirements from stakeholders in remote locations or those who will have only minor
input into the overall requirements. Questionnaires can also be used when you have to
gather input from dozens, hundreds, or thousands of people.
4: Prototyping
Prototyping is a relatively modern technique for gathering requirements. In this
approach, you gather preliminary requirements that you use to build an initial version
of the solution a prototype. You show this to the client, who then gives you
additional requirements. You change the application and cycle around with the client
again. This repetitive process continues until the product meets the critical mass of
business needs or for an agreed number of iterations.
4.