1. Introduction & Life Cycle Models (First chapter)

why do we learn software engineering?

What is software crisis

Programs vs software products

What is Computer Systems Engineering?

Emergence of Software Engineering?

Identify at least two advantages of using high-level languages over assembly languages.

Explain about 'Structured Programming

Identify two important features of a structured program.

Q: Explain about 'Data Structure-Oriented Design (Early 70s)'
http://myrajendrak.blogspot.in/2013/07/data-structure-oriented-design-early-70s.html

Q: State at least two basic differences between control flow-oriented and data flow-oriented design techniques.

Ans.: - Control flow-oriented design deals with carefully designing the program’s control structure. A program's control structure refers to the sequence, in which the program's instructions are executed, i.e. the control flow of the program. But data flow-oriented design technique identifies:
• Different processing stations (functions) in a system
• The data items that flows between processing stations
*****************************************************************************
Object-Oriented Design (80s)

• Object-oriented technique:

-        an intuitively appealing design approach:

-        natural objects (such as employees, pay-roll-register, etc.) occurring in a problem are first identified.

• Relationships among objects:

-        such as composition, reference, and inheritance are determined.

• Each object essentially acts as

-        a data hiding (or data abstraction) entity. 

• Object-Oriented Techniques have gained wide acceptance:

-        Simplicity

-        Reuse possibilities

-        Lower development time and cost

-        More robust code

-        Easy maintenance

Q: State at least five advantages of object-oriented design techniques.

Ans.: - Object-oriented techniques have gained wide acceptance because of it’s:

• Simplicity (due to abstraction)

• Code and design reuse

• Improved productivity

• Better understandability,

Better problem decomposition

• Easy maintenance

*****************************************************************************

***********************************************************************

Evolution of Other Software Engineering Techniques ?

Ans:

• The improvements to the software design methodologies

-        are indeed very conspicuous. 

• In additions to the software design techniques:

-        several other techniques evolved.

-        life cycle models,

-        specification techniques,

-        project management techniques,

-        testing techniques,

-        debugging techniques,

-        quality assurance techniques,

-        software measurement techniques, 

-        CASE tools, etc.

************************************************************************

Differences between the exploratory style and modern software development practices

Ans:

• Use of Life Cycle Models
• Software is developed through several well-defined stages:

-        requirements analysis and specification,

-        design,

-        coding,

-        testing, etc.

• Emphasis has shifted

-         from error correction to error prevention.

• Modern practices emphasize:

-        detection of errors as close to their point of introduction as possible.

• In exploratory style,

-        errors are detected only during testing,

• Now,

-         focus is on detecting as many errors as possible in each phase of development.

• In exploratory style,

-        coding is synonymous with program development.

• Now,

-        coding is considered only a small part of program development effort.

• A lot of effort and attention is now being paid to:

-        requirements specification.

• Also, now there is a distinct design phase:

-        standard design techniques are being used.

• During all stages of  development process:

-        Periodic reviews are being carried out

• Software testing has become systematic:

-        standard testing techniques are available

• There is better visibility of design and code:

-        visibility means production of good quality, consistent and standard documents.

-        In the past, very little attention was being given to producing good quality and consistent documents.

-        We will see later  that increased visibility makes software project management easier.

• Because of good documentation:

-        fault diagnosis and maintenance are smoother now.

• Several metrics are being used:

-        help in software project management, quality assurance, etc.

• Projects are being thoroughly planned:

-        estimation,

-        scheduling,

-        monitoring mechanisms.

• Use of CASE tools.

Software Life Cycle

                  Software Life Cycle 
                           (or)
                 Software Development Life Cycles(SDLC)

• Software life cycle (or software process):

-        series of identifiable stages that a software product undergoes during its life time:

*        Feasibility study

*        requirements analysis and specification,

*        design,

*        coding,

*        testing

*        maintenance

Explain about Feasibility study?

Ans: Feasibility Study

• Main aim of feasibility study:determine whether developing the product

-         financially worthwhile

-         technically feasible.

• First roughly understand what the customer wants:

-        different data which would be input to the system,

-        processing needed on these data,

-        output data to be produced by the system,

-        various constraints on the behavior of the system.

Activities during Feasibility Study

• Work out an overall understanding of the problem.
• Formulate different solution strategies.
• Examine alternate solution strategies in terms of:

*        resources required,

*        cost of development, and

*        development time.

• Perform a cost/benefit analysis:
• to determine which solution is the best.
• you may determine that none of the solutions is feasible due to:

high cost,

resource constraints,

technical reasons.

Explain about Requirements Analysis and Specification?

• Aim of this phase:

-         understand the exact requirements of the customer, 

-         document them properly.

• Consists of two distinct activities:

-         requirements gathering and analysis

-         requirements specification.

Goals of Requirements Analysis

• Collect all related data from the customer:

-         analyze the collected data to clearly understand what the customer wants,

-         find out any inconsistencies and incompleteness in the requirements,

-         resolve all inconsistencies and incompleteness.

Requirements Gathering

• Gathering relevant data:

-         usually collected from the end-users through interviews and discussions.

-         For example,  for a business accounting software:

*         interview all the accountants of the organization to find out their requirements.

• The data you initially collect from the users:

-         would usually contain several contradictions and ambiguities:

-         each user  typically has only a partial and incomplete view of the system.

• Ambiguities and contradictions:

-         must be identified

-         resolved by discussions with the customers.

• Next, requirements are organized:

-         into a Software Requirements Specification (SRS) document.

• Engineers doing requirements analysis and specification:

-         are designated as  analysts.  

Explain about Design?

• Design  phase transforms  requirements  specification:

-          into a  form suitable for implementation in some programming language.

• In technical terms:

-         during design phase,  software architecture is derived from the SRS document. 

• Two design approaches:

-         traditional approach,

-         object oriented approach.

Traditional Design Approach

• Consists of  two activities:

-         Structured analysis

-         Structured design

Structured Analysis Activity

• Identify all the functions to be performed.
• Identify data flow among the functions.
• Decompose each function  recursively into sub-functions. 

-         Identify data flow among the  sub functions as well.

• Carried out using Data flow diagrams (DFDs).
• After structured analysis, carry out structured design:

-         architectural design (or high-level design)

-         detailed design (or low-level design).

Structured Design

• High-level design: 

-         decompose the system into modules, 

-         represent invocation relationships among the modules.

• Detailed design:

-         different modules designed in greater detail:

*         data structures and algorithms for each module are designed.

Object Oriented Design

• First identify various objects (real world entities)  occurring in the problem:

-         identify the relationships among the objects.

-         For example, the objects in a pay-roll software may be:

*         employees,

*         managers,

*         pay-roll register,

*         Departments, etc.

• Object structure

-         further refined to obtain the detailed design.

• OOD has several advantages:

-         lower development effort,

-         lower development time,

-         better maintainability.

Explain about Implementation?

• Purpose of implementation phase (aka coding and unit testing phase):

-         translate(converting) software design into source code.

• During the implementation phase:

-         each module of the design is  coded,

-         each module is unit tested

·         tested independently as a stand alone unit, and debugged,

-         each module is documented.

• The purpose of  unit testing:

-         test if individual modules work correctly. 

• The end product of implementation  phase:

a set of program modules that have been  tested individually.

                                                    *********************

Life Cycle Model

                                                   **********************

Before learning Life Cycle Models first lets we discuss environment in the Software Organisations.

                                            Designation in Software Organisations

• Whenever we enter into the software organisation as a Trainee(fresher)
• after some couple of time we will be Software Engineer
• later Senior Software engineer
• After gaining Experience we may become as a Tech Lead/Team Lead./Module Leader
• Next designation is we have choice either we may try for Project Manager or Business Analysists
• BA(Business Analysists) involves in the Analysis phase

• A software life cycle model (or  process model):

-        a descriptive and diagrammatic model of software life cycle:

-        identifies all the activities required for product development,

-        establishes a precedence ordering among the different activities,

-        Divides life cycle into phases. 

• Several different activities may be carried out in each life cycle phase.

-        For example, the design stage might consist of:

*        structured analysis activity followed by 

*        structured design activity.

Why Model  Life Cycle ?

Ans:

• A written description:

-        forms a common understanding of activities among the software developers.

-        helps  in identifying inconsistencies, redundancies, and omissions in the development process.

-        Helps in tailoring a process model for specific projects.

• Processes are tailored for special projects.

-        A documented process model

·         helps to identify where the tailoring is to occur.

• The development team must identify a suitable life cycle model:

-        and then adhere to it.

-        Primary advantage of adhering to a life cycle model:

·        helps development of software in a systematic and  disciplined manner.

• When a program is developed by a single programmer ---

-        he has the freedom to decide his exact steps.

• When a software product is being developed by a team: 

-        there must be a precise understanding among team members as to when to do what,

-        otherwise it would lead to chaos and project  failure.

• A software project will never succeed if:

-        one engineer starts writing code,

-        another concentrates on writing the test document first,

-        yet another engineer first defines the file structure

-        another defines the I/O for his portion first.

• A life cycle model:

-        defines  entry and exit criteria for every phase.

-        A phase is considered to be complete:

·        only when all its exit criteria are satisfied.

• The phase exit criteria for the software requirements specification phase:

-        Software Requirements Specification (SRS) document is complete, reviewed, and approved by the customer.

• A phase can start:

-        only if its phase-entry criteria have been satisfied.

• It becomes easier for software project managers:

-        to monitor the progress of the project.

• When a life cycle model is adhered(undertaken) to,

-        the project manager can at any time fairly accurately tell,

·        at which stage  (e.g., design, code, test, etc. ) of the project is.

-        Otherwise, it becomes very difficult to track the progress of the project 

·        the project manager would have to depend on the guesses of the team members.

• This usually leads to a problem:

-        known as the  99% complete syndrome.

• Many life cycle models have been proposed.
• We will confine our attention to a few important and commonly used models.

-        classical waterfall model

-        iterative waterfall,

-        evolutionary,

-        prototyping, and

-        spiral model

4. Explain about the phases in Water fall model?

1.21          Iterative water fall model


PHASES IN WATERFALL MODEL:

The simplest, oldest and most widely used process model for software designing is the waterfall model. It was proposed by Royce in 1970.
The essence of this software paradigm is that the process of software designing consists of linear set of distinct phases.

These phases are:

Stage1: Feasibility Study
The goal of feasibility study is to evaluate alternative systems and to purpose the most feasible and desirable system for designing. Five types of feasibility are addressed in this study.

1. Technical feasibility
2. Economic Feasibility
3. Motivational Feasibility
4. Schedule Feasibility
5. Operational Feasibility

Stage2: Requirement Analysis and Specification

The goal of this phase is to understand the exact requirements of the customers and to document them properly. This activity is usually executed together with the customers, as the goal is to document all functions, performance and interfacing requirements for the software designing and management. The requirements describe “what” of a system. This phase produces a large document containing a description of what the system will do without describing how it will be done. This document is known as software requirement specification (SRS) document.

SRS DOCUMENTS:

• This baseline are the references to the future level
• Once the step is completed
• Which can be performed
• Change of people
• We are not making is necessary
• Civil engineering, different people are do different tasks same thing happens to the software also
• Different steps can be followed
• This document also plays a key role to the
• Natural development
• When the requirements are clearly defined this is the best System engineering step

·        Where u try to understand the overall problem identify which of the problem handled by the software

·        Its possible certain requirements may n

·        Certain requirements may need to be done manually, because  automation may not possible whereas other phases can be done automation(sw)

·        Main intention of this step is Understand the overall problem of the context then, identify the responsibilities

Analysis phase

·        We understand the problems in details we understands. Generally this phase is done by the Business Analysists(BA) or Analysists

·        What kind of information is involved, What kind of data is involved

·        What function need to be performed, what are the performances and information is required

·        This part is the analyst part: whose purpose is to identify the clearly defined the requirements which are to be performed to development of the software

·        Along with the analysist you also try to carry out project planning either the part of the same step or if it I s a large project the project planning step may be for separate step

·        And the ……is to identify , how to carry out the project

·        What are the different steps what are the deliverables and what would be the time framed, what would be the resources allocated that is what the project planning is

·        After the analysist is done this step leads to ‘SOFTWRE DESIGN ‘ phase

Software design:

• in this step we translate the requirements into the software architecture
•  and we prepare the database design and so on and this is primarily a technical step
• you may have the Detailed Design document this document may specify individual units   different people will implemented
• and this step the requirements are translated into a implementation framework which will be implemented in the next phase the CODING PHASE, in which the actual programming and implementation is done.
• So you have a design and design is followed by a implementation infact as its notes

• The design itself is divided into two stages (i) high level design and (ii)detailed design , again this would depend the complexity of the task
• you may have the Detailed Design document this document may specify individual units   different people will implemented
• After you have done the implementation
• This work is documented and is known as Software Design Description (SDD document).
• Design document is also very important for future maintenance
• Next phase is coding phase

CODING PHASE

• The information contained in SDD is sufficient to begin the coding Phase
• The source is one of the important deliverable and deliverable which is an executable plan
• at the end of the each step if you recall as I said every step ends with a validation and proper tested.
• Similarly in the waterfall model when we move from one step to another there would be such reviews each step usually end with a review
• These review reports are very important inputs for identifying whether the development proceeded as What are the short comings whether the defects will be detected or addressed so review reports basically a catalog of the how the development went through and its an important inputs to the development team as well as the management team.
• So these are the different deliverables, many of them are very important of which SRS is the one of the baseline
• The coding Phase of software designing involves translation of design specification into a machine readable form(i.e programs).
•  If design is performed in a detailed manner, code generation can be finished easily. 
• This phase is also known as the implementation phase. Here, each component of the design is implemented as a program module.

• The individual units of software are ready
• You get into the next phase

TESTING AND INTEGRATION PHASE

• Each of these program modules is unit tested. The purpose of unit testing is to determine the correct working of individual modules.
• In this all the individual pieces of software are tested and then whole software will put together
• Here objective is to test first ‘the logic ‘ of the individual module
• And then when we put all of them put together then we want to test the interfaces so that they work correctively in a manner on which they intended to work
• So this is the testing and integration phase
• This is followed the actual deployment of the software
• Now the software is ready
• Then the user take the software and take controlling
• So the deployment takes place and we release the software to use people and
• After the deployment there is a ongoing maintenance phase

MAINTENANCE PHASE

• On the maintenance phase we have to make the necessary changes
• If any errors are encountered we have to remove the errors
• If the software is not meeting the performance requirements we may have to review the software and may have to go back to design whether the design have modified or is there any something else to be done in order to improve the performance
• So this is the ongoing step which we generally we call the maintenance phase and this either the software enhanced or is perfected or to be ported new hardware, this is ongoing step which needs to done through the life of the software.

Advantages

1. Simple and easy to use
2. Easily manageable
3. The phase of the model are processed and completed one at a time.
4. Works very well for smaller software projects.

Disadvantages

1. It is often difficult for the customer to state all the requirements explicitly.
2. Real projects rarely follow the sequential flow that the software model proposes.
3. The customer must have patience, as the product is delivered very late in this software process.
4. The model is not suitable for long time software projects.

Now each of these steps are certain deliverables in waterfall Model. Let us talk the different deliverables come out in a given sequence when we perform the various steps

One of the important is the

• Project plan and feasibility report:
• We will be carrying out the project according to the plan
• plan needs to be reviewed as we

The feasibility report defines the cost effectiveness of approach and the whole software project, whether we are investing good or not whether the software is cost effective means the software will give the benefits .

• so the project plan is one deliverable and the feasibility is one deliverable
• one of the important deliverable is the REQUIREMENT DOCUMENT which is also called the Software Requirement Specification(SRS)
• SRS is very important baseline it defines the functions that the software will perform for us
• Obviously this out put SRS will comes from the Analyst Step
• And the next step is the design the document

• The above figure shows the cost effect distribution as we run thru the different spects in the waterfall model . there are different steps are shown here
• Some of the earlier steps I have smaller efforts costs than the subsequent steps
• For example the detailed design , implementation are very effort intensive steps
• The line here is the cumulative have seen its increases rapidly as we progress development
• So accumulated cost increases dramatically as we go from initial steps . because as we move steps to along the time of the programmers , technical people , all these are cost effective factors
• This effort distribution is important to understand because it clearly bringsout that we must take all efforts to remove errors as earlier possible in the life cycle
• We must discover and fix this bugs as early as possible because fixing them subsequently is very costly operation
• Suppose there is a misunderstanding or analysis phase have not clearly identified the functional requirement that if it is not detected at the Review phase by the analysists would be carried over into design, detailed design , implementation and if it is not possible that mistake during the operation time when the user have started using the software . Now inorder to make the corrections we will have to undo the code, deisign etc., go back right upto the analysis phase and identify what have the missed out what are the wrongly understood and carryout the design and implementation and testing again so . Its important such errors are captured as early as possible and they are not allowed to kept into subsequent steps
• So in any software development approach its important to understand how the cost have distributed not only for project planning and emphasizing the error free activity in each step
• Now there are some short coming to the Water Fall Model
• One of the main criticism is for waterfall model is that it goes linearly
• And it assumes all the requirements clearly defined during the analysist phase
• There are many situation where Requirements may not be clearly known, this often happen there is no manual counterpart for that the problem that we are solving if a manual counterpart exists that means the function business function is already been carried out manually and we are planning to automated that then in this case it is easy to
• Here is an example we know that the Railway Reservation is now is in online before that the manual system existed we knew what is the tasks or what are the goal are involved in railway reservation that you want to reserve a seat on a particular train you may want to cancel it , you may get wait listed , wait list have to be arranged and there is a method for arranging all those things were we already defined as functional activities and therefore one can say the is the railway reservation is concerned the manual system existed and therefore it is possible to clearly define the requirements in this case

But there can be other examples where there can be no manual part for example a Central Bank wants to build a knowledge management system it believes that there is so much knowledge that is available its

DEPLOYMENT PHASE

In the real time applications(projects) we have different types of servers. They are:

1. Development Server
2. Integration Server
3. QA Server (Quality Assurance)
4. Production Server

Development Server: It is used by every developer(programmers) to perform unit testing. And every developer’s computer development server is installed.

Integration Server: it is used by all the developers of that project. This server is used to perform Integration testing between modules.

QA Server: is used by the tester to perform the quality check on the project.

Production Server: This is the server used to deploy the final project for customer. Generally this server is available in client’s location.

 

5. Explain about spiral model? 

Spiral Model - A New Approach Towards Software Development

The Waterfall model is the most simple and widely accepted/followed software development model, but like any other system, Waterfall model does have its own pros and cons. Spiral Model for software development was designed in order to overcome the disadvantages of the Waterfall Model.

we discussed about "Waterfall Model", which is one of the oldest and most simple model designed and followed during software development process. But "Waterfall Model" has its own disadvantages such as there is no fair division of phases in the life cycle, not all the errors/problems related to a phase are resolved during the same phase, instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase, this takes much of time of the next phase to solve them. The risk factor is the most important part, which affects the success rate of the software developed by following "The Waterfall Model".

In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it. This model is referred as "The Spiral Model" or "Boehm’s Model".

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and Engineering. These four phases are iteratively followed one after other in order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases. The phases in "Spiral Model" are:

Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle.

Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.

Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same.

Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to TESTING phase.

The process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration almost all possible risk factors, constraints, requirements are identified and in the next iterations all known strategies are used to bring up a complete software system. The radical dimensions indicate evolution of the product towards a complete system.

However, as every system has its own pros and cons, "The Spiral Model" does have its pros and cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task.

Six major activities of each designing spirals are represented by six major tasks:
1. Customer Communication
2. Planning
3. Risk Analysis
4. Software Designing Engineering
5. Construction and Release
6. Customer Evolution

Advantages

1. It facilities high amount of risk analysis.
2. This software designing model is more suitable for designing and managing large software projects.
3. The software is produced early in the software life cycle.

Disadvantages

1. Risk analysis requires high expertise.
2. It is costly model to use
3. Not suitable for smaller projects.
4. There is a lack of explicit process guidance in determining objectives, constraints and alternatives..
5. This model is relatively new. It does not have many practioners unlike the waterfall model or prototyping model.

                                                         1.22          Prototype model

1.22          Explain about Prototype model

/* In development the web based Applications before we start coding we develop a prototype and deliver a prototype to client or customer.

What is Prototype?

Ans:  Prototype is a dummy project developed by HTML Developers to get the approval of customer. Once the customer has approved the project prototype based on the project prototype we develop the code. Our Team Lead or project manager is the responisible to give the prototype to the developer. In the real time projects we develop the java code based on the Prototypes given by the Team Leads.  */

Prototyping is a technique that provides a reduced functionality or limited performance version of the eventual software to be delivered to the user in the early stages of the software development process. If used judiciously, this approach helps to solidify user requirements earlier, thereby making the waterfall approach more effective.
What is done is that before proceeding with design and coding, a throw away prototype is built to give user a feel of the system. The development of the software prototype also involves design and coding, but this is not done in a formal manner. The user interacts with the prototype as he would do with the eventual system and would therefore be in a better position to specify his requirements in a more detailed manner. The iterations occur to refine the prototype to satisfy the needs of the user, while at the same time enabling the developer to better understand what needs to be done.

Disadvantages

1. In prototyping, as the prototype has to be discarded, so might argue that the cost involved is higher.
2. At times, while designing a prototype, the approach adopted is “quick and dirty” with the focus on quick development rather than quality.
3. The developer often makes implementation compromises in order to get a prototype working quickly.

1.23          Evolutinary model

Evolutionary prototyping model

Evolutionary prototyping model is a software development lifecycle model in which software prototype created for demonstration and requirements elaboration. Evolutionary prototyping model includes the four main phases:

Definition the basic requirements

Creating the working prototype

Verification of the working prototype

Changing or elaboration the requirements

Evolutionary prototyping model allows create working software prototypes fast and may be applicable to projects where:

System requirements early are not known in advance

Creating fundamentally new software 

Developers are not confident in software architecture and algorithms 

Advantages:

• The model can be used when the requirements cannot or will not be specified.
• The user can experiment with the system to improve the requirements.
• Benefit not only business results but marketing and internal operations as well.
• Use of EVO brings significant reduction in risk for software projects.
• EVO can reduce costs by providing a structured, disciplined avenue for experimentation.
• EVO allows the marketing department access to early deliveries, facilitating development of documentation and demonstrations.
• Short, frequent EVO cycles have some distinct advantages for internal processes and people considerations.
• The cooperation and flexibility required by EVO of each developer results in greater teamwork.
• Better fit the product to user needs and market requirements.
• Manage project risk with definition of early cycle content.
• Uncover key issues early and focus attention appropriately.
• Increase the opportunity to hit market windows.
• Accelerate sales cycles with early customer exposure.
• Increase management visibility of project progress.
• Increase product team productivity and motivation.

Disadvanges:

• Use of the method is exploratory in nature and therefore constitutes a high-risk endeavor. Strong management is required.
• This method is used as an excuse for hacking to avoid documenting the requirements or design, even if they are well understood. 

What is the Best SDLC MODEL?

Ans: Which software development model(SDLC Model)is best suited for frequently changing requirements and why? What happens if the client's requirements are changing near the release date? What will be the flow of model?

Unfortunately, few people realize that two-word conventional wisdom answer is only partly accurate. It's overly simplistic, illusory, and likely to mask many of the issues that will continue to plague the situation you ask about if you fall into iterative development traps.

Iterative development comes in many popular flavors, such as Rapid Application Development (RAD), Prototyping, Spiral Development, Rational Unified Process (RUP), and Agile Development's several variations. Each is a way to build a little, check it with the users, adjust accordingly, build a little more, check it again, adjust and so on.

Waterfall concepts and misconceptions

Iterative development arose as an alternative to practices which many people equate to the "waterfall" development model. The waterfall has a series of sequential phases: feasibility analysis, requirements definition, system design


Which SDLC MODEL did you use in your Project?
Ans: This is the common question we are asked in Interviews, We can choose any SDLC Model its totally depends on our requirement and project type so we can choose any model .

*********************************************************

6. What is Myths?

Myths: meaning

"A myth, in its simplest definition, is a story with a meaning attached to it other than it seems to have at first; and the fact that it has such a meaning ...

Example of general topics: (just read and understand don’t note down the following example)

Myths in India 

Myth. India is one huge country

Reality: You’ve cracked this most basic myth haven’t you? You’ve learned to approach India as a continent rather than a country. You’ve broken it up – first into north and south, and then into states, cultures, languages.

Myth . India is hot

Reality: You’re moving to Bangalore. Nice move. Okay, it gets hot, but never ‘heat and dust’ hot. And if it ever gets unbearable, the rains always oblige. Bangalore is beautiful and cool after the rain.

Myth . India is spiritual

Reality: Goes without saying. Land of the vedas, yoga, karma and meditation.

And then you come here and meet the Indian Government Official. There’s nothing spiritual about a system that needs money for every move. There’s nothing otherworldly about men who need to be bribed just to do their job.

Myth . India is filled with nasty disease-carrying insects

Reality: Okay, there are mosquitoes. But you know the drill: deet repellents, sprays and maybe even a mosquito net.

Then, as you sit down in the restroom, a panicked periplaneta americana (that’s whacking great cockroach to you and me) leaves its sewery footprints across your back.

Myth . India is filled with snakes

Reality: This is totally wrong

Myth. India is cheap

Reality: Everybody knows that.

And then you move here and pay $20,000 for a car with no handling, no legroom, no bootspace, no leather and no style.

In the same way we have Software myths also there

(note down the )

Software Myths

Software Myths- beliefs about software and the process used to build it - can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. For instance, myths appear to be reasonable statements of fact, they have an intuitive feel, and they are often promulgated by experienced practitioners who “know the score”.

1. Management myth:
2. Programmer myth:
   

Management Myths

Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. 

Myth #1Myth: “State-of-the-art tools are the solution.”

Reality:  Computer aided software engineering9CASE) tools are important for archieving good quality and productivity, yet the majority of software developers do not use them. Even if they are used. “a fool with a tool is still a fool.”.

Myth #2 “If we get behind schedule, we can add more programmers and catch up” (sometimes called the “Mongolian horde” concept).
Reality: Software development is not a mechanical.

Myth #3: The best performer on the team is the most qualified to be the manager.

Many new managers are frustrated to discover that the same skills that made them the best individual contributor don’t work when it comes to managing others.

Reality: The skills that lead to success as an individual contributor quite different from those needed to manage. It’s true that top performers usually are the first ones to be considered for promotion – and they should be. High performance should be a pre-requisite for promotion to a manager – but it shouldn’t be the only consideration. The ability to enable others to improve their performance becomes even more important. High performers often have never struggled in a job, and have no idea why anyone wouldn’t have the same work ethic and want to succeed like they have.

The skills you bring to your new position will remain valuable throughout your career. However, as a manager, your success will also depend on a different set of skills—particularly people skills.

Myth #4: Managers get to tell people what to do, and they do it

As a manager, you’ll finally get to call the shots. Instead of being told what to do, you’ll now get to do the telling, and people will have to do what you say.

Reality: Managers do have more power, authority, status, and access. But these privileges do not guarantee that a manager has influence. High achievers usually do what their managers ask them to do. Then, when they get promoted, they find out that’s not always the case with their former peers or new team.

Influencing the actions of direct reports is just one type of influence. A manager also has to rely on their power of persuasion and collaborative skills to influence peers and others as well.

Myth #5: You have to sell your soul to the devil to be a manager

Most managers are evil, and care about nothing but the bottom line.

Reality: Leaders care about the success of others and the success of the business. While it may be true that managers can’t be friends with their employees, they can be and often are respectful, caring, and fair. They realize that’s the only way to ensure long-term, sustainable high performance.

Myth #6: Managers have a lot of freedom

Many new managers believe they'll have far more freedom to make decisions and take action than they had as individual contributors. Some may also assume that they'll have more free time than before, because they'll have direct reports to handle a lot of the work that needs doing.

Reality: Managers often have far less freedom to act alone than they might have anticipated. There’s a lot more people to look out after, influence, and network with. There’s a whole new set of duties, obligations, and relationships. I’m sure there a lot of CEOs and business owners that sometimes long for the days when they were starting out and had more freedom.

Myth #7: Managers make more money than individual contributors

Myth #8: Managers make less money than individual contributors

Reality: It really depends. Commission based jobs, artists, athletes, and scientists often make more than their managers. Management doesn’t always mean more money – it’s just a different type of work that requires different skills. However, as a general rule of thumb, more money usually comes with greater responsibility.

Myth #9: You can prepare to be a good manager by taking a training course or reading books.

Reality: You can learn only so much through training or reading. The best way to prepare for a management roles is to:

- Get as much practical experience as you can. Look for off the job leadership opportunities, get practice leading meetings and interviewing, practice your influence and relationship building skills, and be seen as a leader well before you’re promoted
- Observe and learn from other managers. Watch what the good ones do and ask them how they do it and why.

Programmer myth:

Myth: Once we write the program and get it to work, our job is done.

Reality: Industry data indicates that 60% to 80%of all effort expended on software will be expended after it is delivered to the customer for its first time.

Myth: “Until I get the program running, I really have no way of assessing its quality.”

Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project- the formal technical review. This has been found to be more effective than testing for finding certain classes of software errors.

Myth: The only deliverable for a successful project is the working program.

Reality: A working program is only one part of a software product which includes programs, documents, and data. Documentation forms the foundation for successful development and, more importantly, provides guidance for the software maintenance task.

7. Core Software Engineering Principles
ans: the various core software engineering principles are:

•  provide value to the customer and the user
• KIS-keep it simple
• maintain the product and project "vision"
• what you produce, others will consume
• be open to the future
• plan ahead for reuse
• think

8. What is Verification and validation ?
Ans:
Verification: Are we building the product right? that is to establish the truth of correspondence between a software product and its specification (veritas= truth)
Validation: Are we building the right Product? that is to establish the fitness of worth of a software product for its intended mission.(valere= to be worth)