Download Software Engineering Fundamentals: Introduction to Software Development Processes and more Exams Introduction to Software Engineering in PDF only on Docsity!
INTRODUCTION
Software is a set of instructions to acquire inputs and to manipulate them to produce the desired output in terms of functions and performance as determined by the user of the Software. Software does not wear out. Software is developed or engineered rather than manufactured. Software both a product and a vehicle for delivering the product.
- Software is classified into two classes:
- Generic software is designed for a broad customer market whose requirements are very common, fairly stable and well understood by the software engineer. - Example : database products
- Customized products are those that are developed for a customer where domain, environment and requirement being unique to that customer cannot be satisfied by generic software. Example : hospital management systems. ✓ There are different software like System Software, Business Software, Embedded Software, Design/Engineering/Scientific Software, Artificial Intelligence (AI) Software.
Software Engineering is the establishment and use of sound engineering principles to obtain software economically that is reliable and works efficiently on real machines.
- The layers of Software Engineering are:- •.1. Quality focus – It is the bedrock that supports Software Engineering. •.2. Process layer – This layer act as a binding medium that holds all the layers together and enables development of high quality software, in time. •.3. Methods layer – It includes a set of tasks such as requirement analysis, program construction, testing and support. •.4. Tools - Software Engineering tools provide automated or semi- automated support for the process and methods
SOFTWARE PRODUCT AND PROCESS
Software Product is outcomes of a software project.
- It includes programs which can run on any computer, documents in the form of hardcopy and virtual forms and relevant data and pictures.
- It is the main driving force that drives business decision making.
- It is built by software engineering approach, by applying a process that leads to high quality software.
- It depends on software process for its stability, quality and control. Software Process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result high-quality software at low cost is produced in stipulated time.
- It defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology.
- It provides stability, control and organization to an activity that can if left uncontrolled, become quite chaotic.
- Selecting a process depends upon the software being built.
CHARACTERISTICS OF SOFTWARE PROCESS
- Predictability : determines how accurately that outcome of following process in a can be predicted before the project is completed. - If process is not predictable, then it is of limited use.
- Testability and Maintainability determines how much it is easy to test and maintain the software.
- Early defect removal and Defect prevention, a continuous process that determines the throughput in software development.
- Process Improvement determines the productivity and quality of the software. To satisfy the engineering objectives of quality improvement and cost reduction, the software process must be improved.
SOFTWARE PROCESS MODEL
- Software Process Model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.
- All software development can be characterized as a problem solving loop in which four distinct stages are encountered:
- Status Quo represents the current state of affairs.
- Problem definition identifies the specific problem to be solved.
- Technical development solve the problem through the application of some technology.
- Integrating Solution delivers the results to those who requested the solution in the first phase.
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) SDLC is the process of developing software through business needs, analysis, design, implementation and maintenance. Software has to go through various phases before it is born which are as follows:
- Generating a Concept – A concept comes from the users of the software. Client will specify his requirements. For example, a Pizza Hut may need software to sell pizza.
- Requirements analysis –software team will analyze the requirement and prepare requirement document that will explain every functionality that are needed by the owner.
- The requirement document will be the main document for developers, testers and database administrators.
- Other detailed documents many be needed. For example, the architectural design which is a blueprint for the design with the necessary specifications for the hardware, software, people and data resources.
- Development: After the detailed requirement documents (some companies have design documents instead of requirement documents), the developers start writing their code (program) for their modules.
- On the other hand, the testers in the QA (Quality Assurance) Department start writing Test Plans (one module=1 test plan), test cases and get ready for testing.
- Testing : the code (programs) are compiled together and to make a build. This build is now tested by the software testers (QA Testers)
- Production : the application (software) goes into production (i.e., it will be handed over to the owner).
- End : When the business grows and the software does not meet the demand or for some reason or the client does not need the software, then SDLC ends.
LINEAR SEQUENTIAL MODEL
- A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user (e.g., input approaches and output formats).
- The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed.
- Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done.
Advantages ✓ It could serve as the first system. ✓ The customer doesn’t need to wait long as in the Linear Model. ✓ Feedback from customers is received periodically and the changes don’t come as a last minute surprise.
Disadvantages ✓ Customer could believe the prototype as the working version. ✓ Developer also could make the implementation compromises where he could make the quick fixes to the prototype and make is as a working version. ✓ Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realize that no consideration was given to the overall quality of the software in the rush to develop the prototype
RAPID APPLICATION DEVELOPMENT (RAD) MODEL
♦ (^) Rapid Application development (RAD) is an incremental software development
process model that emphasizes an extremely short development cycle (anywhere from 60-90 days).
♦ If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods. ♦ The time constraints imposed on a RAD project demand “scalable scope”. If a business application can be modularized in a way that enables each major function to be completed in less than three months , it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole. ♦ The RAD model is a high-speed adaptation of the linear sequential model / Waterfall
model.
♦ The RAD approach encompasses the following phases:
- Business Modeling is the information flow among business functions is modeled in a way that answers the following questions:
1.a. What information drives the business processes?
1.b. What information is generated?
1.c. (^) Who generates it?
1.d. Where does the information flow?
1.e. Who processes it?
- Data Modeling is the information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics called attributes of each objects are identified and the relationships between the objects are then defined.
- Process Modeling the data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement the business functions. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.
- Application generation RAD assumes the use of fourth generation techniques. RAD process works to use the automated tools to facilitate the construction of the software.
- Testing and turnover Since the RAD processes emphasize reuse, many of the program components have already been tested. This saves time, money and the overall time to test an application also reduces considerably.
♦ Disadvantages
✓ For Large (but scalable) projects, RAD requires sufficient resources to create the right number of RAD teams. ✓ Not all applications are compatible for RAD. If a system cannot be properly modularized, building components for RAD will be problematic. ✓ RAD is not appropriate when technical risks are high. This normally occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability. ✓ It requires equal commitment from both customers and developers. One sided commitment can be disastrous.
EVOLUTIONARY SOFTWARE PROCESS MODELS
Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.
- The spiral model, originally proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.
- It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases.
- During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.
- The spiral model is intended for large, expensive and complicated projects.
- The activities in this model can be organized like a spiral. The spiral has many cycles.
- Each cycle in the spiral
- Begins with the identification of objectives for that cycle and the different alternatives possible for achieving the objectives and the imposed constraints. This will also involve identifying uncertainties and risks involved.
- The next step is to develop strategies that resolve the uncertainties and risks.
- Each cycle of the spiral is completed by a review, which covers all the products developed during that cycle, including plans for the next cycle.
- The spiral model works for developed as well as enhancement projects.
- The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented, prototype-oriented, simulation-oriented or some other approach.
- The development spiral consists of four quadrants Quadrant 1: Determine Objectives, Alternatives, and Constraints Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks Quadrant 3: Develop, Verify, Next-Level Product
Quadrant 4: Plan Next Phases
Quadrant 1: Determine Objectives, Alternatives, and Constraints Activities performed in this quadrant include:
- Establish an understanding of the system or product objectives—namely performance, functionality, and ability to accommodate change.
- Investigate implementation alternatives—namely design, reuse, procure, and procure/ modify
- Investigate constraints imposed on the alternatives—namely technology, cost, schedule, support, and risk.
Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks Activities performed in this quadrant include:
- Select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints.
- The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Boehm describes these activities as follows:
- This may involve prototyping, simulation, benchmarking (A measurement of the quality of an organization's policies, products, programs, strategies, etc., and their comparison with standard measurements, or similar measurements of its peers.), reference checking, administering user questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.
- The outcome of the evaluation determines the next course of action. If CRITICAL OPERATIONAL AND/OR TECHNICAL ISSUES (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant.
- If the alternative chosen is “operationally useful and robust enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic)” This brings us to Quadrant 3. Quadrant 3: Develop, Verify, Next-Level Product
- If a determination is made that the previous prototyping efforts have resolved the CRITICAL OPERATIONAL AND/OR TECHNICAL ISSUES , activities to develop, verify, next-level product are performed.
- As a result, the basic “waterfall” approach may be employed—meaning concept of operations, design, development, integration, and test of the next system or product iteration. - If appropriate, incremental development approaches may also be applicable.
Quadrant 4: Plan Next Phases
- Each cycle of the model ends with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves CRITICAL OPERATIONAL AND/OR TECHNICAL ISSUES ; and reviews plans and identifies CRITICAL OPERATIONAL AND/OR TECHNICAL ISSUES to be resolved for the next iteration of the spiral.
- Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations
COMPONENT ASSEMBLY ( DEVELOPMENT) MODEL ♦ The component-based development model composes applications from pre - packaged software components (called classes). ♦ It incorporates many of the characteristics of the spiral model. It is evolutionary in nature , demanding an iterative approach to the creation of software.
- Verify quality Always make testing a major part of the project at any point of time. Testing becomes heavier as the project progresses but should be a constant factor in any software product creation.
- Control changes Many projects are created by many teams, sometimes in various locations, different platforms may be used, etc. As a result it is essential to make sure that changes made to a system are synchronized and verified constantly.
- Building Blocks of Rational Unified Process
RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following:
- Roles (who) – A Role defines a set of related skills, competencies and responsibilities.
- Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
- Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result. - The tasks are categorized into nine disciplines: - Six "engineering disciplines" - Business Modeling - Requirements - Analysis and Design - Implementation - Test - Deployment - Three supporting disciplines - Configuration and Change Management - Project Management - Environment
AGILE UNIFIED PROCESS (AUP)
- Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP).
- It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.
- The AUP applies agile techniques including test driven development (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity.
- AUP has only seven disciplines : (Unlike the RUP)
- Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.
- Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.
- Test. Perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
- Deployment. Plan for the delivery of the system and to execute the plan to make the system available to end users.
- Configuration Management. Manage access to project artifacts. This includes not only tracking artifacts versions over time but also controlling and managing changes to them.
- Project Management. Direct the activities that take place within the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.
- Environment. Support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.
- The Agile UP is based on the following philosophies:
- Your staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are interested, but doesn't force them upon you.
- Simplicity. Everything is described concisely using a handful of pages, not thousands of them.
- Agility. The Agile UP conforms to the values and principles of the agile software development and the Agile Alliance.
- Focus on high-value activities. The focus is on the activities which actually count, not every possible thing that could happen to you on a project.
- Tool independence. You can use any toolset that you want with the Agile UP. The recommendation is that you use the tools which are best suited for the job, which are often simple tools.
- You'll want to tailor the AUP to meet your own needs.
SOFTWARE PROCESS CUSTOMIZATION AND IMPROVEMENT
♦ A process is also not a static entity. Improving the quality and reducing the cost of products are fundamental goals of any engineering discipline. In the context of software, as the productivity and quality are determined largely by the process, to satisfy the engineering objectives of quality improvement and cost reduction, the software process must be improved. ▲ Having process improvement as a basic goal of the software process implies that the software process used is that it supports its improvement. This requires ■ Evaluating the existing ■ Understanding the weakness in the process.
- Key Process Areas : a Key Process Area (KPA) identifies a cluster of related activities that, when performed together, achieve a set of goals considered important.
- Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
- Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
- Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
- There are five levels defined along the continuum of the CMM and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. •.1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process. •.2. Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted. •.3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). •.4. Managed - the process is quantitatively managed in accordance with agreed-upon metrics. •.5. Optimizing - process management includes deliberate process optimization/improvement.
SOFTWARE METRICS
Measure: a measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process.
Measurement: Measurement is the act of determining a measure metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”
- When a single data point has been collected (e.g., the number of errors uncovered in the review of a single module), a measure has been established. Measurement occurs as the result of the collection of one or more data points (e.g., a number of module reviews are investigated to collect measures of the number of errors for each).
Metric: A software metric relates the individual measures in some way (e.g., the average number of errors found per review or the average number of errors found per person- hour expended on reviews.
Indicator : An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.
- An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the process to make things better.
A software engineer collects measures and develops metrics so that indicators will be obtained.
Software metrics can be classified into three categories: product metrics, process metrics, and project metrics. ✓ PRODUCT METRICS describe the characteristics of the product such as size, complexity, design features, performance, and quality level. ✓ PROCESS METRICS can be used to improve software development and maintenance.
- Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time of the fix process. ✓ PROJECT METRICS describe the project characteristics and execution.
- Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity. ✓ Some metrics belong to multiple categories.
- Examples include the in-process quality metrics of a project are both process metrics and project metrics. SOFTWARE QUALITY METRICS
- Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project.
- They are more closely associated with process and product metrics than with project metrics.
- They can be divided further into end-product quality metrics and in-process quality metrics. The essence of software quality engineering is to investigate the relationships among in-process metrics, project characteristics, and end-product quality, and, based on the findings, to engineer improvements in both process and product quality.
- Proper metrics need to be selected. Improper metrics can optimize the performance of a product development sub-process at the expense of global sub-optimization.
- Improper metrics can require significant effort to collect data and develop without providing meaningful information of any real benefit.
Criteria for effective metrics are:
- Keep them simple
- Keep them to a minimum
- Base them on business objectives and the business process - avoid those that cause dysfunctional behavior
