Software Engineering Notes Part-1

Software Engineering is  an engineering approach for software development.The basic principle of software engineering is to use structured, formal and disciplined methods for building and using systems.The outcome of software engineering is an efficient and reliable software product.

Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels  of  the  programs  increase  exponentially  with  their  sizes.  Software  engineering  helps  to reduce  this  programming  complexity.  Software  engineering  principles  use  two  important techniques  to  reduce  problem  complexity:  abstraction  and  decomposition.  The  principle  of abstraction  implies  that  a  problem  can  be  simplified  by  omitting  irrelevant  details.  In  other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant  for  certain  purpose  and  suppress  other  aspects  that  are  not  relevant  for  the  given purpose.  Once  the  simpler  problem  is  solved,  then  the  omitted  details  can  be  taken  into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem. 
The other approach to tackle problem complexity is decomposition.  In  this  technique,  a  complex  problem  is  divided  into several  smaller  problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will  not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution  of  the  different  components  can  be  combined  to  get  the  full  solution.  A  good decomposition  of  a  problem  should  minimize  interactions  among  various  components. 

System Requirement Specification(SRS):
It is obtained after excessive discussions with the users.Software requirement specification (SRS) is a document that completely describes what the proposed software should do without describing how software will do it.SRS is important and difficult task of a System Analyst.

Characteristics of SRS:

• Correct
• Complete and Unambiguous
• Verifiable
• Consistent
• Traceable
• Modifiable

Software Life Cycle Models:

A  software  life  cycle  model  (also  called  process  model)  is  a  descriptive  and  diagrammatic representation of the software life cycle. A life cycle model represents  all the activities required to  make  a  software  product  transit  through  its  life  cycle  phases.  It  also  captures  the  order  in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which  life  cycle  model  is  followed,  the  basic  activities  are  included  in  all  life  cycle  models though the activities may be carried out in different orders in different life cycle models. During any life cycle phase, more than one activity may also be carried out. A software life cycle model is a particular abstraction representing a software life cycle.Such a model may be:

Activity-centered----Focusing on the activities of software development

Entity-centered----Focusing on the work products created by these activities

A software life cycle model is often referred to as a Software Development Life Cycle(SDLC).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.

Waterfall Model:

The Waterfall Model was first Process Model to be introduced.

The waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement. The waterfall approach is the earliest approach that was used for software development.

Requirement Gathering and Analysis	Capture all the possible requirement of the system to be developed and documented in a software requirement.
System Design	Helps in specifying hardware and system requirements and also helps in defining overall system architecture.
Implementation	With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.
Integration and Testing	All the units developed in the implementation phase are integrated into a system after testing of each unit. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.
Integration and System Testing	During  the  integration  and  system  testing  phase,  the  modules  are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number ofsteps.  During  each  integration  step,  the  partially  integrated  system  is  tested  and  a  set  of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing  is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: α – testing: It is the system testing performed by the development team. β –testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.
Deployment of System	Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.
Maintenance	Maintenance of a typical software product requires much more than the  effort necessary  to  develop  the  product  itself.  Many  studies  carried  out  in  the  past  confirm  this  and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60  ratios. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving  the  implementation  of  the  system,  and  enhancing  the  functionalities  of  the system according to the customer’s requirements. This is called perfective maintenance. Porting  the  software  to  work  in  a  new  environment.  For  example,  porting  may  be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

Advantages of waterfall model:

• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
• In this model phases are processed and completed one at a time. Phases do not overlap.
• Waterfall model works well for smaller projects where requirements are very well understood.

 Disadvantages of waterfall model:

• Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

• This model is used only when the requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.