Skip to main content

Software Engineering UNIT-2

 UNIT – II( From Press man Book And Google)

Process models: 

  • Prescriptive models

  • Water fall model

  • Incremental

  • Evolutionary and specialized process models

  • Unified process

Software engineering practice:

  • Communication practices,

  • Planning practices, 

  • Modeling practices, 

  • Construction practice and deployment


Process Models:

Software Processes

The term software specifies to the set of computer programs, procedures and associated documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used.

A software process is the set of activities and associated outcome that produce a software product. Software engineers carry out these activities. 


These are four key process activities, which are common to all software processes. These activities are:


  • Software Specifications: The functionality of the software and constraints on its operation must be defined.

  • Software Development: The software to meet the requirement must be produced.

  • Software validation: The software must be validated to ensure that it does what the customer wants.

  • Software Evolution: The software must evolve to meet changing client needs.


The Software Process Model:

A software process model is a specified definition of a software process, which is presented from a particular perspective. Models, by their nature, are a simplification, so a software process model is an abstraction of the actual process, which is being described. Process models contain activities, which are part of the software process, software product, and the roles of people involved in software engineering. 


Prescriptive Software Models:

  • Prescriptive software models are the models, which prescribe the components make up a software model, including the activities like

  • The inputs of the activities

  • Outputs of the activities,   

  • Quality assurance performance, 

  • Changes in management and so on




1. A workflow model: This shows the series of activities in the process along with their inputs, outputs and dependencies. The activities in this model perform human actions.


2. A dataflow or activity model: This represents the process as a set of activities, each of which carries out some data transformations. It shows how the input to the process, such as a specification is converted to an output such as a design. The activities here may be at a lower level than activities in a workflow model. They may perform transformations carried out by people or by computers.

3. A role/action model: This means the roles of the people involved in the software process and the activities for which they are responsible.


Program vs. Software:


Software is more than programs. 

Any program is a subset of software, and it becomes software only if documentation & operating procedures manuals are prepared.


There are three components of the software as shown in fig:


Program vs. Software

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals. Examples of documentation manuals are: Data Flow Diagram, Flow Charts, ER diagrams, etc.

3. Operating Procedures: Operating Procedures consist of instructions to set up and use the software system and instructions on how react to the system failure. Example of operating system procedures manuals is: installation guide, Beginner's guide, reference guide, system administration guide, etc.

Software Development Life Cycle (SDLC):

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents all the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken. all life cycle models be carried out in distinct orders in different life cycle models. During any life cycle stage, more than one activity may also be carried out.


Need of SDLC


The development team must determine a suitable life cycle model for a particular plan and then observe to it.

Without using an exact life cycle model, the development of a software product would not be in a systematic and disciplined manner. When a team is developing a software product, there must be a clear understanding among team representative about when and what to do. A software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-entry criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage cannot be recognized. Without software life cycle models, it becomes tough for software project managers to monitor the progress of the project.


Software Development Life cycle (SDLC)


SDLC represents the process of developing software. SDLC framework includes the following steps:






The stages of SDLC are as follows:


Stage 1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain experts in the industry.

Planning for the quality assurance requirements and identifications of the risks associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the data for the customer wants to build, who will be the end user, what is the objective of the product. Before creating a product, a core understanding or knowledge of the product is very necessary.


Stage 2: Defining Requirements

Once the requirement analysis is done, the next stage is to represent and document the software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which contains all the product requirements to be constructed and developed during the project life cycle.

Stage 3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design of the software project. This phase is the product of the last two, like inputs from the customer and requirement gathering.

Stage 4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The implementation of design begins concerning writing code. Developers have to follow the coding guidelines described by their management and programming tools like compilers, interpreters, debuggers, etc. are used to develop and implement the code.

Stage 5: Testing

After the code is generated, it is tested against the requirements to make sure that the products are solving the needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

Stage 6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage 7: Maintenance

Once the client starts using the developed systems, then the real issues come up and requirements to be solved from time to time. In this procedure thae care is taken for the developed product is known as maintenance.


Water fall model:


The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

  • Waterfall Model is also called the classic life cycle or the linear sequential model, the waterfall model suggests a systematic, sequential approach to software development.

  • Waterfall Model begins at the system level and progresses through Analysis, Design, Coding, Testing, and Support. 


Water fall model is a step by step approach like as shown in the Diagram.




Software requirements analysis: 

  • The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer ("analyst") must understand the information domain for the software, as well as required function, behavior, performance, and interface. 

  • Requirements for both the system and the software are documented and reviewed with the customer.

  • Defining Requirements can be accomplished through SRS- Software Requirement Specification document

  •  SRS contains all the product requirements to be constructed and developed during the project life cycle.


Designing the Software:

  • Software design is actually a multistep process that focuses on four distinct attributes of a program: 

  • Data Structure, 

  • Software Architecture, 

  • Interface Representations, 

  •  Procedural (algorithmic) Detail. 

  • The design process translates requirements into a representation of the software that can be assessed for quality before coding begins. Like requirements, the design is documented and becomes part of the software configuration.




Code Generation: 

  • After designing the requirements, the design must be translated into a machine readable form. That is the implementation of software.

  • The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanistically.

Testing:

Once code has been generated, program testing begins. 

  • The testing process focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results. 

  • We have different types of testing techniques like white box, black box and so on.

Support: 

Software will undergo change after it is delivered to the customer.

  •  Change will occur because errors have been encountered, 

  • Because the software must be adapted to accommodate changes in its external environment (e.g., a change required because of a new operating system or peripheral device), or because the customer requires functional or performance enhancements. 

  • Software support/maintenance reapplies each of the preceding phases to an existing program rather than a new one.

Four types of change are encountered during the support phase: They are

  • Correction. Even with the best quality assurance activities, it is likely that the customer will uncover defects in the software. Corrective maintenance changes the software to correct defects.

  • Adaptation. Over time, the original environment (e.g., CPU, operating system, business rules, external product characteristics) for which the software was developed is likely to change. Adaptive maintenance results in modification to the software to accommodate changes to its external environment.

  • Enhancement. As software is used, the customer/user will recognize additional functions that will provide benefit. Perfective maintenance extends the software beyond its original functional requirements.

  • Prevention. Computer software deteriorates due to change, and because of this, preventive maintenance, often called software reengineering, and must be conducted to enable the software to serve the needs of its end users.

  • Preventive maintenance makes changes to computer programs so that they can be more easily corrected, adapted, and enhanced. 

Maintenance:

  • This phase confirms the software operation in terms of more efficiency and less errors. If required, the users are trained on, or aided with the documentation on how to operate the software and how to keep the software operational. 

  • The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. 

This phase may face challenges from hidden bugs and real-world unidentified problems


Draw Backs of Waterfall Model: 

  • Real projects rarely follow the Waterfall model. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.

  • It is often difficult for the customer to state all requirements explicitly. The linear sequential model is difficulty for accommodating the natural uncertainty that exists at the beginning of many projects.

  • The customer must have patience. A working version of the program(s) will not be available until late in the project time-span.



     Incremental Model:




Incremental Model is a process of software development where requirements are broken down into multiple standalone modules of software development cycle. 

Incremental development is done in steps from analysis design, implementation, testing/verification, maintenance.


  • Combines elements of the waterfall model applied in an iterative fashion 

  • Each linear sequence produces deliverable “increments” of the software 

  • The first increment is often a core product 

  • The core product is used by the customer; Based on evaluation results, a plan is developed for the next increment. 

  • Used when requirements are well understood, Multiple independent deliveries are identified, Work flow is in a linear fashion within an increment and is staggered between increments. 

  • Iterative in nature; focuses on an operational product with each increment.

  • Provides a needed set of functionality sooner while delivering optional components later.  

  • Useful, when staffing is too short for a full-scale development. 

  • The incremental process model, is an evolutionary approach and is iterative in nature ,

  • The incremental model focuses on the delivery of an operational product with each increment 

  • Increments can be planned to manage technical risks. 





Comments

Popular posts from this blog

Advanced Structural Modeling

                                                                      Unit II                                                     Advanced Structural Modeling  A relationship is a connection among things. In object-oriented modeling, the four most important relationships are dependencies, generalizations, associations, and realizations.  Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the different relationships. Dependency A dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it, but not necessarily the reverse. Graphically, a dependency is rendered as a dashed line  A plain, unadorned dependency relationship is sufficient for most of the using relationships you'll encounter. However, if you want to specify a shade of meaning, the UML defines a number of stereotypes that may be applied to dependency relationships. There are 17 such stereo

Design Patterns UNIT-2

 A Case Study: Design a Document Editor ¾     This chapter presents a case study in the design of a "What-You-See-Is-What-You-Get" (or "WYSIWYG") document editor called Lexi. ¾     We'll see how design patterns capture solutions to design problems in Lexi. ¾     A WYSIWYG representation of the document occupies the large rectangular area in the center. ¾     The document can mix text and graphics freely in a variety of formatting styles. ¾     Surrounding the document are the usual pull-down menus and scroll bars, and a collection of page icons for jumping to a particular page in the document.    Design Problems: Seven problems in Lexis's design: Document Structure: The choice of internal representation for the document affects nearly every aspect of Lexis's design.    All editing, formatting, displaying, and textual analysis will require traversing the representation.   The way we organize those impacts design information.

Artificial Intelligence

  Chapter 1                                                                                                                                 ( Source: Google) Intelligence What is “Intelligence”? -- Everyone has his own definition but no one has a precise one at that -- Everyone agrees that humans and dogs are intelligent, trees are not What is AI? Two dimensions: 1.Thought processes and reasoning (internal) 2.Behavior (external) Two factors for measuring success along each dimension: 1.Success in terms of fidelity to human performance 2.Success in terms of an ideal performance measure, called rationality. Acting humanly: Turing Test •Turing Test -- Proposed by Alan Turing in 1950 -- Designed to provide a satisfactory operational definition of intelligence -- A computer passes the test if a human interrogator, after posing some written questions, cannot tell whether the written responses come from a person or from a computer -- No physical interaction between the interrogator and the c