Skip to main content

Software Engineering UNIT-1

SOFTWARE ENGINEERING


UNIT – I( collected from Pressman Text Book and Google)

Introduction to software Engineering:

  • The Evolving role of Software

  • Software

  • Changing nature of software

  • Legacy software

  • Software myths

Software process:

  • Layered technology

  • Process frame work

  • CMMI 

  • Process patterns

  • Assessment

  • Personal and team process models

  • Process technology

  • Product and Process


Introduction to software engineering:

Software Engineering provides a standard procedure to design and develop software.

 

What is Software Engineering?

 

The term software Engineering is the product of two words, Software and Engineering.

The software is a collection of integrated programs.

Computer programs and related documentation such as requirements, design models and user manuals

 

Software = Program + Documentation + Operating Procedures

 

Engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and improve frameworks, processes, etc.

Software Engineering is an Engineering branch related to the evolution of software product using well-defined scientific principles, techniques, and procedures. The result of software engineering is an effective and reliable software product.

Characteristics of software:

  1. Software is developed or engineered, it is not manufactured in the classical sense. Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quallity is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software.

2. Software does not wear out; hsowever it deteriorates due to change.

3. Software is custom built, rather than assembling existing components-

Although the industry is moving towards the component based construction, most software continues to be custom built.


“Software is virtual. That is, software can be used using proper hardware. And we can only use it. Hardware we can touch, and see . Thus software never gets manufactured, they are developed.


In the case of software, a good design will introduce good software, if done through the design. But in the case of hardware, the design is only the half way. In the manufacturing phase it may introduce quality problem ,Thus it can be said that the software is developed or engineered, not manufactured”.

Software does not wear out; however it deteriorates due to change”.


CHARACTERISTICS OF HARDWARE:



In the above given figure, we can see how a hardware, with time, wear out. This is often called the “bathtub curve”.At the beginning there can be faults which, then gets corrected and reaches the steady state. And then after certain period of service, the hardware starts to show errors again and at one time it wear out.


Characteristics of Good software

 A software Product Can be judged by Satisfying the following:

1. Operational (Ready for Use)

2. Transitional (The period of Transition)

3. Maintenance (The process of Preserving a Condition)


Operational tells us how well the software works on its operations and can be Measured on

The following.


  • Budget: Define a Plan in Iterations

  • Usability: usability is the degree to which software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.

  • Efficiency: Efficiency  is used to show the effort put in to develop the application and to quantify its user-satisfaction

  • Correctness: Correctness determines how users can interact with the software and how the software should behave when it is used correctly.

  • Functionality: Functionality is the ability of the system to do the work for which it was intended

  • Dependability: The dependability of a system reflects the user's degree of trust in that system.

  • Security: Software security is the idea of engineering software so that it continues to function correctly under malicious attack

  • Safety: The condition of being protected from risk.

Transitional: The characteristic of a process or period of transition. Transitional aspect is important when the software is moved from one platform to another.

  • Portability: The ability of software to be transferred from one machine or system to another.

  • Interoperability: The ability of computer systems or software to exchange and make use of information.

  • Reusability: In computer science and software engineering, reusability is the use of existing assets in some form within the software product development process

  • Adaptability: The capacity to be modified for a new use or purpose.

Maintenance:

Maintenance aspect briefs about how well software has the capabilities to maintain itself in the ever-changing environment

  • Modularity:  refers to the extent to which a software/Web application may be divided into smaller modules

  • Maintainability: The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment."

  • Flexibility:  it refers to designs that can adapt when external changes occur.

  • Scalability: Scalability in software engineering refers to designing software systems in such a manner that, as the number of users of the system increases the software will continue to function with comparable response times.

Characteristics of a Good Software Engineer:

  • Exposure to systematic methods, i.e familiarity with software engineering principles.

  • Good technical knowledge of the project range (Domain knowledge).

  • Good programming abilities.

  • Good communication skills. These skills comprise of oral, written, and interpersonal skills.

  • High motivation.

  • Sound knowledge of fundamentals of computer science.

  • Intelligence.

  • Ability to work in a team

  • Discipline, etc.

 

Changing nature of software:

 

Nowadays, seven broad categories of computer software present continuing challenges for software engineers .which is given below:

  • System Software:
    System software is a collection of programs which are written to service other programs. Some system software processes complex but determinate information structures. Other system applications process largely indeterminate data. Sometimes when, the system software area is characterized by the heavy interaction with computer hardware that requires scheduling, resource sharing, and sophisticated process management.

  • Application Software:
    Application software is defined as programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operation or management technical decision making. In addition to conventional data processing applications, application software is used to control business functions in real time.

  • Engineering and Scientific Software:
    This software is used to facilitate the engineering function and task. However, modern applications within the engineering and scientific area are moving away from the conventional numerical algorithms. Computer-aided design, system simulation, and other interactive applications have begun to take a real-time and even system software characteristic.

  • Embedded Software:
    Embedded software resides within the system or product and is used to implement and control features and function for the end-user and for the system itself. Embedded software can perform the limited and esoteric function or provide significant function and control capability.

  • Product-line Software:
    Designed to provide a specific capability for use by many different customers, product line software can focus on the limited and esoteric marketplace or address the mass consumer market.

  • Web Application:
    It is a client-server computer program which the client runs on the web browser. In their simplest form, Web apps can be little more than a set of linked hypertext files that present information using text and limited graphics. However, as e-commerce and B2B applications grow in importance. Web apps are evolving into a sophisticated computing environment that not only provides a standalone feature, computing function, and content to the end user.

  • Artificial Intelligence Software:
    Artificial intelligence software makes use of a non numerical algorithm to solve a complex problem that is not amenable to computation or straightforward analysis. Application within this area includes robotics, expert system, pattern recognition, artificial neural network, theorem proving and game playing.


Legacy software:


Legacy software are older programs that are developed decades ago.

  • The quality of legacy software is poor because it has in-extensible design, convoluted code, poor and nonexistent documentation, test cases and results that are not achieved.

  • As time passes legacy systems evolve due to following reasons:

  • The software must be adapted to meet the needs of new computing environment or technology.

  • The software must be enhanced to implement new business requirements.

  • The software must be extended to make it interoperable with more modern systems 

  • database

  • The software must be re-architected to make it viable within a network environment.


Software myths: 

 

We have three types of myths, they are 

1)  Management myth   2) Customer myth     3) Practitioner’s myth


Management Myths:

Management myths. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slip- ping, and improve quality, a software manager often grasps at belief in a software myth, if that belief will lessen the pressure

  • Myth1: We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know?

  • Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it streamlined to improve time to delivery while still main- taining a focus on quality? In many cases, the answer to all of these questions is "no."

  • Myth2: My people have state-of-the-art software development tools, after all, we  buy them the newest computers.

  • Reality: It takes much more than the latest model mainframe, workstation, or PC to do high-quality software development. Computer-aided software engineering (CASE) tools are more important than hardware for achieving good quality and productivity, yet the majority of software developers still do not use them effectively.

  • Myth3: If we get behind schedule, we can add more programmers and catch up 

  • Reality: Software development is not a mechanistic process like manufacturing. Adding people to a late software project makes it later." At first, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. People can be added but only in a planned and well-coordinated manner

  • Myth4: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.

  • Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsourced software projects.


Customer Myths:

  • A customer who requests computer software may be a person,, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and ultimately, dissatisfaction with the developer.

  • Myth1: A general statement of objectives is sufficient to begin writing programs— we can fill in the details later.

  • Reality: A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and validation criteria is essential. 

  • These characteristics can be determined only after thorough communication between customer and developer 

  • Myth2: Project requirements continually change, but change can be easily accommodated because software is flexible.

  • Reality: It is true that software requirements change, but the impact of change varies with the time at which it is introduced .The customer can review requirements and recommend modifications with relatively little impact on cost. When changes are requested during software design, the cost impact grows rapidly. 


Practitioner’s Myths

Myths that are still believed by software practitioners during the early days of software, programming was viewed as an art form. Old ways and attitudes die hard 

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

  • Reality:  Someone once said that "the sooner you begin 'writing code', the longer   it'll take you to get done 

  • Myth2: Until I get the program "running" I 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. Software reviews are a "quality filter" that have been found to be more effective than testing for finding certain classes of software defects

  • Myth3: The only deliverable work product for a successful project is the working program.

  • Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.

  • Myth4: Software engineering will make us create voluminous and unnecessary documentation and will invariably

  • .Reality: Software engineering is not about creating documents. It is about creating quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times.

The importance of Software engineering is as follows:

  1. Reduces complexity: Big software is always complicated and challenging to progress. Software engineering has a great solution to reduce the complication of any project. Software engineering divides big problems into various small issues. And then start solving each small issue one by one. All these small problems are solved independently to each other.

  2. To minimize software cost: Software needs a lot of hardwork and software engineers are highly paid experts. A lot of manpower is required to develop software with a large number of codes. But in software engineering, programmers project everything and decrease all those things that are not needed. In turn, the cost for software productions becomes less as compared to any software that does not use software engineering method.

  3. To decrease time: Anything that is not made according to the project always wastes time. And if you are making great software, then you may need to run many codes to get the definitive running code. This is a very time-consuming procedure, and if it is not well handled, then this can take a lot of time. So if you are making your software according to the software engineering method, then it will decrease a lot of time.

  4. Handling big projects: Big projects are not done in a couple of days, and they need lots of patience, planning, and management. And to invest six and seven months of any company, it requires heaps of planning, direction, testing, and maintenance. No one can say that he has given four months of a company to the task, and the project is still in its first stage. Because the company has provided many resources to the plan and it should be completed. So to handle a big project without any problem, the company has to go for a software engineering method.

  5. Reliable software: Software should be secure, means if you have delivered the software, then it should work for at least its given time or subscription. And if any bugs come in the software, the company is responsible for solving all these bugs. Because in software engineering, testing and maintenance are given, so there is no worry of its reliability.

  6. Effectiveness: Effectiveness comes if anything has made according to the standards. Software standards are the big target of companies to make it more effective. So Software becomes more effective in the act with the help of software engineering.




II) Software engineering – A Layered Approach





Quality focus: 

An Engineering approach must have a focus on Quality which provides the continuous improvement. This is Bedrock that supports software Engineering. 

Process: 

Defines a frame work for effective delivery of software engineering technology this is a Foundation for software Engineering. 

Methods: 

Provide technical Support for building software, methods encompasses many tasks including communication, requirement analysis, Design modeling, Program construction, Testing and support.

Tools :

Provide semi-automatic and automatic support for the process and methods.

Process Frame Work: 

Framework is a Standard way to build and deploy applications. 

Software Process Framework is a foundation of complete software engineering process. Software process framework includes all set of umbrella activities. 

It also includes number of framework activities that are applicable to all software projects.

https://media.geeksforgeeks.org/wp-content/uploads/20190403214215/Untitled-Diagram15.png

A generic process framework encompasses five activities which are given below one by one:

  1. Communication:
    In this Communication activity, communication with customers and other stakeholders, is done ,requirement gathering is done.

  2. Planning:
    In this planning activity, we discuss the technical related tasks, work schedule, risks, required resources etc.

  3. Modeling:
    Modeling is about building representations of things in the ‘real world'. In modeling activity, a product’s model is created in order to better understanding and requirements.

  4. Construction:
    In software engineering, construction is the application of set of procedures that are needed to assemble the product. In this activity, we generate the code and test the product in order to make better product.

  5. Deployment:
    In this activity, a complete or non-complete products or software are represented to the customers to evaluate and give feedback. on the basis of their feedback we modify the products for supply better product.

 

Umbrella activities include:

  • Risk management

  • Software quality assurance(SQA)

  • Software configuration management(SCM)

  • Measurement

  • Formal technical Reviews(FTR)

 

 

 

 

Capability Maturity Model Integration (CMMI) 

 

Capability Maturity model is a process level improvement training and appraisal program. Which is Administered by the CMMI Institute, Developed by SEI(Software Engineering Institute). 

Key Process Areas (KPA’s):
Each of these KPA’s defines the basic requirements that should be met by a software process in order to satisfy the KPA and achieve that level of maturity.

Organization selects specific improvements that best meet its business objectives and minimize risk.

We have 5 different levels of CMMI. These Levels are called capability levels.

 

 5 levels of CMMI are 

  • Level 1: Performed (Initial)

  • Level 2: Managed 

  • Level 3: Defined 

  • Level 4: Quantitatively managed

  • Level 5: Optimized 

 

  • Level 1: Initial. The software process is characterized and done for a particular purpose as necessary, and occasionally even in a state of complete confusion and disorder. Few processes are defined, and success depends on individual effort.

 

  • Level 2: Repeatable.   Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

 

  • Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into an organization-wide software process. All projects use a documented and approved version of the organization's process for developing and supporting software. This level includes all characteristics defined for level 2.

 

  • Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures. This level includes all characteristics defined for level 3.

 

  • Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies. This level includes all characteristics defined for level 4.

 

 

Maturity Level 1: Initial

  • Success of organizations depends on the competence and heroics (Behavior ) of the people in the organization and not on the use of proven processes.

  • Organization usually does not provide a stable environment but Software project success depends on having quality people. 

  •  Useful work done by the people but without objects like planning, quality , time schedule etc. 

Maturity Level 2:Managed

  • At this level the organization set a quantitative quality goal for both software process and software maintenance.

  • This process are selected that significantly contribute to overall process performance

  • Organization has achieved all the specific and generic goals. 

Maturity Level 3: Defined

  • Processes are well characterized, and understood, described in standards, procedures, tools and methods. 

  • Process are described more detail than level2 

  • To Establish and maintain a description of the process. 

  • To collect information derived from planning and performing the process. 

  • Process are managed proactively using an understanding of the interrelationship of the process activities 

  • Detailed measures of the process its work product s and its services. 

Maturity Level 4: Quantitatively Managed

  • Sub-processes are selected to contribute to the overall process performance. 

  • As criteria in managing processes the quantitative objects for quality are established.

  • Quantitative objectives are based on: -Needs of a customer -End users -Organization -Process implements

  • For these processes, detailed measures of process performance are collected and statistically analyzed 

 

Maturity Level 5: Optimizing

  • Focuses on continually improving process performance through: 

    • -Incremental technological improvements 

    • -Innovative technological improvements

  •  Both processes are the organization’s set of measurable improvement activities 

Staged model 

  • This model is used if you have no clue of how to improve the process for quality software.

  • It gives a suggestion of what things other organizations have found helpful to work first.

Advantages of CMMI

  • Provides a framework for benchmarking the process.

  • CMM is not prescriptive; it does not tell an organization how to improve, but what to improve. 

  • Provides good “common sense” Engineering and Management practices. 

  • Helps forge a shared vision of what software process improvement means for the organization. 

  • Define a set of priorities for addressing software problems. 

Supports measurement of process by providing framework for performing reliable and consistent appraisal.

PROCESS PATTERNS:

  • Software Process is defined as collection of Patterns

  • Process pattern provides a template

  • Process Template , It has - Pattern Name, -Intent Type, -Task pattern Stage pattern-Phase Pattern. 

  • Initial Context 

  • Problem

  • Solution

  • Resulting Context

  • Related Patterns

PROCESS ASSESSMENT:

The process assessment 

  • Does not specify the quality of the software or whether the software will be delivered on time or will it stand up to the user requirements.

  • It attempts to keep a check on the current state of the software process with the intention of improving it.

 

 

 

 

Approaches To Software Assessment:

  • A software assessment (or audit) can be of three types.

  • A self-assessment (first-party assessment) is performed internally by an organization's own personnel.

  • A second-party assessment is performed by an external assessment team or the organization is assessed by a customer.

  • A third-party assessment is performed by an external party or (e.g., a supplier being assessed by a third party to verify its ability to enter contracts with a customer).

  • Software process assessments are performed in an open and collaborative environment. They are for the use of the organization to improve its software processes.

  • Standard CMMI assessment (SCAMPI)

  • CMM based appraisal for internal process improvement

  • SPICE(ISO/IEC 15504)

  • ISO 9001:2000 for software

 

Personal And Team Software Process:

  • Personal software process

--Planning

--High Level Design

--High Level Design Review

--Development

--Postmortem

  • The Personal Software Process (PSP) shows engineers how to manage the quality of their projects.

  •  Make commitments they can meet.

  • Improve estimating and planning, reduce defects in their products.

PSP emphasizes the need to record and analyze the types of errors one can make, so one can develop strategies to eliminate them.

  • Personal Software Process costs 70 percent of the cost of software development, the skills and work habits of engineers largely determine the results of the software development process. • 

  • Based on practices found in the CMMI, the PSP can be used by engineers as a guide to a disciplined and structured approach to developing software. 

  • The PSP is a prerequisite for an organization planning to introduce the TSP. 

 

  • Team software process

--Goal of TSP(Team Software Process)

--Build self-directed teams

--Motivate the teams

--Acceptance of CMM level 5 behavior as normal to   accelerate software process       improvement

--Provide improvement guidance to high maturity organization

  • The Team Software Process (TSP), along with the Personal Software Process, helps the high performance engineer to ensure quality software products

 Creating secure software products improves process management in an organization.

 

PSP 

TSP 

Planning 

Launch High level Design 

High level Design 

Implementation 

High level Design Review 

Integration 

Development 

Test 

Postmortem 

Postmortem 

 

Product and Process:

  • The product is the final result of a development cycle. The process is a sequence or set of steps that should be followed to create a product.  

 

  • Product development focus is on final outcome. The process focuses on each step to be followed during software product development.

Product:
In the context of software engineering, Product includes any software manufactured based on the customer’s request. This can be a problem solving software or computer based system. It can also be said that this is the result of a project.

  • Process:
    Process is a set of sequence steps that have to be followed to create a project. The main purpose of a process is to improve the quality of the project. The process serves as a template that can be used through the creation of its examples and is used to direct the project.

  • The main difference between a process and a product is that the process is a set of steps that guide the project to achieve the convenient product. While on the other hand, the product is the result of a project that is manufactured by a wide variety of people.

 

 

 

 

 








 

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