Unit - 2
Software engineering Principles and Practice
Communication, planning, modelling, building, and deployment are generic framework activities, and umbrella activities create a basic architecture for software engineering activity. You will learn the general concepts and principles that apply to framework activities in this section.
As you plan and develop software, you must examine a wide range of concepts, principles, methodologies, and tools. It reflects the finer points of the software development process, such as technical considerations and how-tos: the stuff you'll need to create high-quality computer software.
Why is it important?
Everyone participating in the construction of a computer-based system or product has a road map for effectively arriving at a goal thanks to the software process. You'll need practice to get the level of detail you'll need to drive down the road. It shows you the locations of the bridges, checkpoints, and forks. It assists you in comprehending the concepts and principles that must be comprehended and followed in order to drive safely and quickly. It teaches you how to drive, including when to slow down and when to accelerate. Practice is what you do day in and day out as software goes from an idea to a reality in the context of software engineering.
Communication practice
Customer requirements must be acquired through a communication (also known as requirements elicitation) activity before they can be evaluated, modelled, or described. A consumer has an issue that a computer-based solution might be able to solve. A developer answers to a customer's assistance request. The process of communication has begun. However, the path from communication to comprehension is frequently paved with potholes.
One of the most difficult tasks facing software engineers is effective communication (among technical peers, with customers and other stakeholders, and with project managers). We'll talk about communication concepts that apply to all types of communication within a software project in this context.
Communication between two or more parties is always the first step in developing software. The first step in communication principles is to collect or obtain information from the customer.
Principle 1: Listen
Instead of constructing your response to the speaker's remarks, try to concentrate on the speaker's words. If something is unclear, ask for clarification, but don't interrupt too often. As a person is speaking, never become a source of contention with your words or actions (9 e.g., rolling your eyes or shaking your head).
Principle 2: Prepare before you communicate
Before you meet with others, take the time to understand the problem. If necessary, do some study to learn the language of the business domain. If you're in charge of running a meeting, make sure you have an agenda prepared ahead of time.
Principle 3: Someone should facilitate the activity
A leader should be present at every communication meeting (a facilitator)
(1) To keep the conversation moving in a positive direction,
(2) to arbitrate any disagreements that arise, and
(3) to guarantee that other principles are followed.
Principle 4: Face–to-face communication is best
However, it usually works better when there is another representation of the relevant data available. A participant might, for example, make a drawing or a "strawman" paper to serve as a debate point.
Principle 5: Take notes and documentation decisions
Things have a tendency to fall through the gaps. Someone involved in the communication should help to establish trust among team members and establish a shared goal for the group.
Principle 6: Stay focused, modularize your discussion
The more people who are involved in a conversation, the more likely it is that the conversation will jump from one issue to the next. The facilitator should keep the discourse modular, moving from one topic to the next as the conversation progresses. The facilitator should keep the discourse modular, only addressing one topic at a time.
Principle 7: If something is unclear, draw a picture
Only so far can verbal communication get you. When words fail to convey something, a sketch or drawing can help.
Principle 8:
(a) Once you agree to something, move on;
(b) If you can’t agree to something, move on;
(c) If a feature or function is unclear and cannot be clarified at the moment move on.
Communication, like any other aspect of software engineering, takes time. Instead of constant iteration, participants should acknowledge that many topics require discussion and that "moving on" is sometimes the greatest way to achieve communication agility.
Principle 9: Negotiation is not a contest or a game. It works best when both parties win
The software engineer and the customer must negotiate functions and features, priorities, and delivery deadlines in a variety of situations. If the team has worked successfully together, everyone has a same aim. As a result, bargaining will necessitate compromise on the part of all sides.
Generic task set for Communication
1. Determine who your main customer and other stakeholders are.
2. Meet with the primary customer to discuss the "context free questions" that characterize the project.
● Business requirements and values
● End-user characteristics and requirements.
● User-visible outputs are required.
● The limitations of the business.
3. Create a one-page written project scope statement that is subject to change.
4. Discuss the scope statement with stakeholders and make any necessary changes.
5. Work with customers/end users to establish the following: • Resulting outputs and inputs
● Key software functions, features, and behavior.
● Business risks that are specified by the customer.
6. Create a concise textual explanation of scenarios, outputs/inputs, features/functions, and dangers (e.g., a series of lists).
7. Iterate on each user scenario, feature, function, and behaviour using customer-defined priorities.
8. Assign user scenarios, features, functions, and behaviours to customer-defined priorities.
9. Review and arm as needed the information acquired throughout the communication activity with the consumer and other stakeholders.
10. Get ready for the action of planning.
Key takeaway
The process of communication has begun. However, the path from communication to comprehension is frequently paved with potholes.
Communication between two or more parties is always the first step in developing software. The first step in communication principles is to collect or obtain information from the customer.
The planning activity establishes a set of management and technical procedures that enable the software team to create a road map for achieving the strategic aim and objective. Planning provides a roadmap for the software team to move quickly through the project development process.
Principles
The following are some guidelines:
1) Know the project's scope: It's impossible to use a roadmap if the team doesn't know where they're going. As scope represents the range within which development takes place, it gives the software team a destination.
2) Involve the client in the planning process: - the customer establishes project priorities and limits. Customer involvement is vital because while directly communicating with the software team, customers can negotiate on delivery order, timelines, and other project-related issues.
3) Recognize that planning is iterative: - a project plan is bound to change due to unforeseen circumstances or personal reasons, so the plan must be adjusted to reflect these changes. The incremental model requires replanting, which occurs after each software increment is delivered and user input is received and changes are made.
4) Make an educated guess based on what you know: - The team works well together. If the information is reliable, estimating gives reliability and convenience to the software team if the efforts, costs, and task estimations are accurate.
5) When defining the plan, keep risk in mind: - Risk is an occurrence that occurs when a cause results in unfavorable outcomes since risk can have a large impact and a high probability on a project, potentially destroying it. As a result, adequate risk management is necessary.
6) Be realistic: - The project should be achievable. All practical considerations must be taken into account. Plan should be dynamic enough to account for all reasons such as delays, mistakes, and incorrect decisions trailing due to technical issues or team members' personal reasons.
7) As you design the plan, adjust the granularity: - Granularity refers to the level of detail in a specification. Because some activities are repeated and take longer to complete, the granularity of the project plan must be adjusted. When a result, as you design the plan, adjust the granularity.
8) Determine how you will accomplish quality: – the most effective mechanism for ensuring quality during project development. Formal technical review is a meeting held by technical employees to identify problems at any level of development, with the goal of improving quality by eliminating defects. This is why it is stated so clearly to attain quality.
9) Describe how you plan to deal with change: – In any level of the software development process, good quality software must be well prepared to accept changes requested by customers. Changes in the project have an impact on the project's cost and schedule, thus it's critical to consider them. As a result, explain how you plan to deal with change.
10) Keep track of the plan at all times and make modifications as needed: - Monitor project progress on a daily basis; all team members should engage in planning activities so that they will acknowledge the need to catch up on a lagging schedule.
Generic task set for Planning:
- Reevaluate project scope.
- Assess risks.
- Develop and/or refine user scenarios.
- Extract functions and features from the scenarios.
- Define technical functions and features that enable software infrastructure.
- Group functions and features (scenarios) by customer priority.
- Create a coarse granularity project plan.
● Define the number of projected software increments.
● Establish an overall project schedule.
● Establish projected delivery dates for each increment.
8. Create a fine granularity plan for the current iteration.
● Define work tasks for each functional feature.
● Estimate effort for each work task.
● Assign responsibility for each work task.
● Define work products to be produced.
● Identify quality assurance methods to be used.
● Describe methods for managing change.
9. Track progress regularly.
● Not progress areas(e.g., schedule slippage).
● Make adjustments as required.
Key takeaway
The planning activity establishes a set of management and technical procedures that enable the software team to create a road map for achieving the strategic aim and objective.
Models are helpful in gaining a better grasp of the actual item that needs to be developed or designed. Models are depicted at several levels of abstraction, with the first depicting software from the perspective of the consumer, and the second depicting software at a more technical level.
There are two types of models that are made: -
1) Analysis model
2) Design model
Analysis Model: –
Represent the customer's demand, which may contain algorithmic programme or process specifications. Three domains are included in the analysis model.
a) Information domain
b) Functional domain
c) Behavioral domain
Fig 1: Analysis model
Analysis Modeling principles
1) The problem's information domain must be expressed clearly: – To depict the information domain, the analysis model employs a "data flow diagram," which comprises the following details: input flow into the system, output flow in the system, and data collecting by data store to gather data in the system.
2) The purpose of software must be clearly defined: - Because functions are processes that convert input flow to output flow, the specification must be precise.
3) The system's behavior must be well defined: - The state transition diagram is used in the analysis model to clearly illustrate the behavior of the system.
4) A clear hierarchy between information, function, and behaviour must be demonstrated: - information, function, and behaviour of the system must be represented using a correct hierarchy, which allows for easy design.
5) The analysis should be explicit enough to translate it into a design model: if the requirement analysis is clear and simple, design will be straightforward.
Design Model:
The design model gives a detailed specification for the development of software. The design model entails
a) Architectural design
b) User interface design
c) Component level details
Fig 2: Design model
Design Modeling principles
1) The design should be able to be traced back to the analysis model: – employing elements if the analysis model is built.
2) Think about the architecture of the system you're going to build: – The following is an example of architectural design. The following are architectural design styles: a) Data Concentration Architecture; b) Data Flow Architecture; and c) Main / Subprogram Architecture
3) Data should take precedence over function design: - Data modelling is significant because it demonstrates relationships between distinct data objects, as represented by entity relationship diagrams.
4) Both an internal and external interface must be created: – All internal and external interfaces must be designed properly for proper data flow between systems or from the external environment to the system.
5) User interface design must meet all of the user's requirements: - The design must be basic and easy to utilise for the end user.
6) Because cohesion measures a module's functional strength, all functions in a single module should be highly cohesive for appropriate design, which is why component level design should be functionally independent.
7) Components must be loosely related to the external environment: In the modelling system, components must be loosely coupled to one another and to the external environment.
8) The design module should be simple to comprehend: Because simple modules are easier to test, debug, and alter, the design module should be simple.
9) Accept that design modelling is an iterative process: - A good design should be able to absorb all changes.
Key takeaway
Models are helpful in gaining a better grasp of the actual item that needs to be developed or designed. Models are depicted at several levels of abstraction, with the first depicting software from the perspective of the consumer, and the second depicting software at a more technical level.
The construction activity entails a series of coding and testing tasks that result in operating software that can be delivered to the client or end-user. Coding can take the form of:
(1) direct creation of programming language source code;
(2) automatic generation of source code using an intermediate design-like representation of the component to be built; or
(3) automatic generation of executable code using a fourth generation programming language in modern software engineering work.
Coding Principle and Concepts
Closely related programming style, programming languages, and programming methodologies are the principles and concepts that govern the coding activity. There are a few essential principles that can be stated, however:
Preparation principles: Before you create a single line of code, make sure you've done the following:
1. Recognize the issue you're attempting to resolve.
2. Know the fundamental ideas and concepts of design.
3. Select a programming language that satisfies all of the software's requirements as well as the environment in which it will run.
4. Choose a programming environment that includes tools to help you do your job faster.
5. Write a set of unit tests to run once the component you've coded is finished.
Coding principles: Before you start creating code, make sure you:
1. Follow structured programming approach to constrain your algorithm.
2. Choose a data structure that will suit the design's requirements.
3. Recognize the programme architecture and provide consistent user interfaces.
4. Make your conditional statement as straightforward as feasible.
5. Design nested loops in a way that allows them to be easily tested.
6. Use appropriate variable names and adhere to other coding conventions in your area.
7. Make your code self-documenting.
8. Create an easy-to-understand graphic layout.
Validation principles: After you've finished your initial pass of coding, make sure you:
1. Build architectural infrastructure
Examine the architectural layout.
Components that enable architectural infrastructure should be coded and tested.
Obtain architectural patterns that can be reused.
To guarantee interface integrity, test the infrastructure.
2. Build a software component
Examine the design at the component level.
Make a unit test suite for the component.
Data structures and the interface are code components.
Internal algorithms and processing functions should be coded.
Examine the code as it is being written.
Check for accuracy.
Ascertain that coding standards have been followed.
Check to see if the cod is self-documenting.
3. Unit test the components
Perform all unit tests.
Correct any inaccuracies that have been discovered.
Unit tests should be re-applied.
4. Completed components should be integrated into the architectural infrastructure.
Testing Principles
Glen Myers presents a number of criteria in a famous book on software testing that might be used as testing objectives:
● Testing is a method of executing code with the goal of detecting an error.
● A excellent test case is one that has a high chance of uncovering an error that has yet to be detected.
● A successful test is one that uncovers an error that has yet to be identified.
For some software developers, these goals require a significant shift in perspective. They change the count to the widely held belief that a successful test is one that finds no errors. Our goal is to create tests that systematically reveal different types of problems while using the least amount of time and effort possible. These mistakes can be fixed later.
Principle 1: All tests should be traceable to customer requirements
The purpose of software testing is to find flaws. As a result, the most serious faults are those that cause the programme to fail to achieve its requirements (from the customer's perspective).
Principle 2: Tests should be planned long before testing begins
As soon as the requirements model is ready, test planning may begin. As soon as the design model is completed, detailed specification of test cases can begin. As a result, all tests may be planned and prepared prior to generating any code.
Principle 3: The pareto principle applies to software testing
Simply put, the Pareto principle states that 80% of all faults discovered during testing can be traced back to 20% of all software components. The issue is, of course, isolating and carefully testing these questionable components.
Principle 4: Testing should begin “in the small” and progress toward testing “in the large.”
Individual components are usually the focus of the first tests that are designed and completed. As the testing proceeds, the emphasis changes to locating flaws in integrated clusters of components and, eventually, the complete system.
Principle 5: Exhaustive testing is not possible
Even for a relatively small application, the number of path permutations (possible combinations) is extremely huge. As a result, it is impossible to test every potential combination of pathways. However, covering programme logic and ensuring that all circumstances in the component-level design have been checked is doable.
Deployment
The delivery, support, and feedback actions are all part of the deployment activity. Due to the evolutionary nature of modern software process models, deployment occurs multiple times as software progresses towards completion. During each delivery cycle, the client and end-users receive an operational software increment with useable functions and features. Any software project's delivery of a software increment is a significant milestone. As the team prepares to deliver an increment, there are a few critical principles to remember:
Principle 1: Customer expectations for the software must be managed
● Too often, the consumer expects more than the team has offered, resulting in rapid disappointment. As a result, unproductive feedback is generated.
● The software engineer must avoid giving contradictory messages to the customer (e.g., promising more than you can reasonably deliver in the time frame provided or delivering more than you promise for one software increment and then less than promised for the next).
Principle 2: A complete delivery package should be assembled and tested
● All executable software, support data files, support papers, and other necessary material should be assembled on a CD-ROM or other media (including Web-based downloads) and properly beta-tested with actual users.
● All scripts for installation and other operating elements should be thoroughly tested.
Principle 3: A support regime must be established before the software is delivered
● When an end user has an issue or a query, he or she wants prompt responses and accurate information.
● If help is sporadic or non-existent, the consumer will quickly grow unsatisfied. So that the software team can analyze the types of assistance sought, support should be planned, support materials should be provided, and proper record-keeping procedures should be implemented.
Principle 4: Appropriate instructional materials must be provided to end users
● More than just software is delivered by the software team.
● Appropriate training aids (if needed) should be produced, as well as troubleshooting guides.
Principle 5: Buggy software should be fixed first, delivered later
Some software companies publish low-quality increments under time constraints, telling customers that issues "will be remedied in the next release." This is a blunder. "Customers will forget you delivered a high-quality product a few days late, but they will never forget the issues that a low-quality product caused them," there's a saying in the software industry. Every day, the software reminds them."
Key takeaway
The delivery, support, and feedback actions are all part of the deployment activity. Due to the evolutionary nature of modern software process models, deployment occurs multiple times as software progresses towards completion. During each delivery cycle, the client and end-users receive an operational software increment with usable functions and features.
System engineering refers to a set of top-down and bottom-up approaches to navigating the hierarchy. A "world view" is usually the first step in the system engineering process. To put it another way, the complete company or product area is reviewed to ensure that the correct commercial or technological environment can be developed.
The world view is fine-tuned to focus more intently on a single topic of interest. The requirement for selected system elements is examined within a specific domain. Finally, work on the analysis, design, and building of a specific system element begins. A very broad framework is provided at the top of the hierarchy, and detailed actions performed by the respective engineering disciplines are conducted at the bottom.
The world view (WV) is made up of a number of domains (D1), each of which can be a system or a system of systems in and of itself.
WV = {D1 D2 D3………,Dn }
Each domain is made up of distinct elements (Ej), each of which plays a specific function in achieving the domain's and component's objectives and goals
Di = {E1 E2 E3 …… Em}
Finally, each element is implemented by defining the technical components (Ck) that enable the element to perform its required function:
Ej = {C1, C2 C3 …….. C k}
A component can be a computer programme, a reusable programme component, a module, a class or object, or even a programming language statement in the context of software.
Fig 3: System engineering hierarchy
It's worth noting how the system engineer's work emphasis narrows as she or he progresses down the above-mentioned ladder. Furthermore, the world view depicts a clear specification of overall functioning, allowing the engineer to comprehend and domain the product or system in the appropriate situation.
Key takeaway
System engineering refers to a set of top-down and bottom-up approaches to navigating the hierarchy. A "world view" is usually the first step in the system engineering process.
Organizations evaluate their current business processes and develop new approaches to increase productivity, efficiency, and operational costs through business process engineering. New business processes, how to diagnose flaws with an organization's current approach, and how to restructure, reconstruct, and monitor processes to ensure they are effective are all covered by business process engineering.
To accomplish major changes, Business Process Engineering (BPE) employs a tried-and-true systematic approach based on the most recent experiences and research. Through the most effective use of enabling technologies and organizational methods, the BPE process assists clients in fundamentally rethinking and reinventing the business processes required to meet the firm's strategic objectives.
Essentially, business process engineering (or reengineering) is the study of a business and the creation of wholly new, highly efficient processes. BPR can have an impact on a company's mission and vision, as well as entail dangerous business changes that can affect culture, climate, and lead to job losses.
This is not to be confused with Business Process Management (BPM), which has similar titles and obviously does similar work. However, BPM is concerned with analyzing existing processes and finding ways to improve them, usually by reworking/redesigning them to be more efficient using new technology and automation, for example. It's less hazardous, doesn't usually have a significant impact on business culture, and its primary goal is to simplify and improve existing processes.
Business process re-engineering examines the company's operations, assesses process needs, eliminates those that aren't needed, and develops whole new processes. When compared to BPM, reengineering is often significantly more expensive, with larger risks and more extreme effects, yet the two can be considered as typically complementary.
Business Process Engineering Approach
The Business Process Engineering (BPE) Approach entails the following:
● Recognizing the Current Mode of Operation (PMO). We'll put together a team of experts to examine your present procedures, technology, and systems. As a result, a complete PMO business process model will be created, displaying interrelationships and dependencies between people, systems, and processes. This will serve as the benchmark against which suggested improvements and actual implementations will be measured.
● Determining the Future Operational Mode (FMO). Based on your business objectives and our combined expertise of industry best practises, we'll work with you to form an advisory team to create an FMO business process model.
● Transition Plan and Gap Analysis There will be a gap analysis of needed business process changes and a transition to the FMO strategy. You'll learn about the business strategy, timelines, personnel, and system/process evolution that will occur.
● Implementation. We'll assist you in determining whether the anticipated results will be reached by trialing and adopting new system or operational process changes. We'll repeat the applicable PMO, FMO, Gap Analysis, and Transition Planning processes if more system and operational process changes are required.
Within the requirements engineering discipline, the following is a proposed framework. It include capturing and modelling business processes, eliciting business and technical requirements for the application, and proposing process improvements required for successful application implementation. Although the framework was created for a specific case study, it is not restricted to that domain. The framework's core process aspects are depicted in Figure.
Fig 4: Conceptual Framework for Business Process Engineering
● The following are examples of what business process capture, analysis, and model building entail. The business process's initial boundaries are determined, and a fundamental grasp of the process is gained. After that, the procedure is documented and modelled. The actors in the process are investigated, and service user groups are identified. The actions that each user group engages in are identified and modelled. Observations, interviews, and brainstorming sessions are utilised to extract requirements at this stage.
● Vision and criteria for the application are defined. The following steps are taken to define an application's vision and needs. To develop high-level functional specifications, stakeholders' requirements are gathered and mapped into service features. Questionnaires are created and disseminated to the user groups that have been identified. This endeavor should be guided by a clear vision and a viable business model. Any conversation with authorities should start here.
● Prototyping for the support of business processes. The requirements specification is used to create and implement a service prototype. The prototype's goal is to collect and validate all of the user's requirements, as well as give more concrete services like a notification service.
● Demonstration and trial work on a prototype. Trial work is critical not only for app functioning and performance evaluation, but also for the educational process. Because process flaws are becoming apparent, ideas for process adjustments must be properly articulated and offered to all process participants. Original process description and functional needs of the new service, as well as their effects on the business process, must be included in the regularized rules. Each process modification must also be described and represented clearly. The users must be able to understand the new process model.
● Reengineering of business processes. Collecting recommendations directly from process players is the only approach to offer appropriate process improvements. Their timely response is beneficial from both a technological and a social standpoint. Process actors are considered domain experts in their respective fields. As a result, needs specifications should be fine-tuned, and input from users on process improvements should be gathered. Questionnaires, interviews, small group discussions, and specialist seminars are all appropriate strategies.
● The deployment of services and processes. Finally, the enhanced process and service are implemented and put into action. The first stage is to bring together all of the stakeholders. The requirements may vary, so representatives from user groups should be involved in all development rounds, including deployment. It is strongly advised that enough user training be provided, as well as the assistance of service specialists. This phase's important success factors are as follows. The goal is to ensure service quality through regular presentations of development activities and control of changing requirements. Any modification that has an impact on the process is quickly incorporated into the new process model and discussed with the actors, with the possibility of implementation in the following cycle.
Key takeaway
Essentially, business process engineering (or reengineering) is the study of a business and the creation of wholly new, highly efficient processes. BPR can have an impact on a company's mission and vision, as well as entail dangerous business changes that can affect culture, climate, and lead to job losses.
Product engineering is the process of designing and creating a device, assembly, or system so that it may be manufactured as a finished product for sale via a product manufacturing process. Cost, producibility, quality, performance, dependability, serviceability, planned lifespan, and user features are typically addressed through product engineering. These product features are often desired in order to make the finished product appealing to its intended market and a successful contributor to the organization's company that wants to deliver the product to that market.
It entails product design, development, and transition to manufacture. The phrase refers to the process of creating a product's concept as well as the design and development of its mechanical, electronic, and software components. Product engineering refers to the process of moving a product from its initial design and development to mass production.
For example, defining the feature set, designing the optics, designing the mechanical and ergonomic design of the packaging, developing the electronics that control the various components, and developing the software that allows the user to see the pictures, store them in memory, and download them to a computer are all part of the engineering of a digital camera.
Product engineering is a branch of engineering that deals with the design and manufacture of products.
Who is a Product Engineer?
A Product Engineer is a "superhero" who must combine the skills of two different jobs: Business Analyst and Project/Delivery Manager. This is a person who is familiar with the market and ensures that the product meets the expectations of the customer. The Product Development Engineer's tasks include understanding the challenges and interests of users and developing a prototype that can provide answers. They also look into what's popular and trendy on the market and in the industry as a whole. Another issue of the Product Engineer is the money required for end-to-end product development, as well as the viability and return on investment (ROI) of the proposed product.
In order to have access to all of the information they require, the Product Engineer typically requires a good communication environment.
Area of responsibility
● During ramp-up and volume manufacturing, product engineers develop the yield road map and oversee fulfillment.
● Determine and implement steps to increase yield, test optimization, and product cost-ability.
● Define a qualifying strategy and conduct a feasibility study.
Product engineers serve as a technical link between the component development team and the production side (Front End and Back End), particularly after the development phase and qualification when high-volume manufacturing is in operation.
Product engineers balance the cost of tests and test coverage, which might affect production fall-off, to increase product quality and ensure product reliability. Customers' failure analysis requests are supported by them.
Knowledge and skills
The product engineer must be extremely knowledgeable in the following areas:
● Statistical methods and tools
● Manufacturing process
● Software, hardware and systems implementation
● Product reliability and qualification
● Physical analysis methods
● Computer-aided design and simulation programs
● Specific technology
● Strong product Knowledge
● Strong analytic work methodology and problem solving skills
● Continuous Improvement Knowledge
Product Engineering Benefits and Importance for Business
The IT industry provides a plethora of opportunities for businesses and can greatly boost their performance. At the same time, developing a fantastic software solution that is both budget and time management friendly can be a significant problem. One of the many advantages of using Product Engineering Service for your company is that it can help you with this arduous procedure. Let's look at some of the others.
● To begin with, it aids in the creation of a software product development plan. To stay ahead of the competition, your product must be innovative. Your product gains value as a result of innovation. A new idea, on the other hand, should always be put to the test. When starting something new and venturing off the regular path, there are usually additional dangers. In this instance, working with a Product Engineering Company can be quite beneficial to your company. They can confirm the feasibility of your proposal by collecting a large amount of data on potential product functionality.
● Software has become an integral aspect of business growth and now accounts for a considerable portion of ROI spending. As a result, improved software testing methods will enable you to meet your business goals in the shortest period possible while still delivering a high-quality end product. With Product Engineering Services, you can rest assured that your product has been thoroughly analyzed and tested to achieve the highest level of quality and user satisfaction.
● You may focus on achieving business goals, marketing, and, overall, successfully implementing your business strategy by outsourcing the product development process to Product Engineering services.
Key takeaway
Product engineering is the process of designing and creating a device, assembly, or system so that it may be manufactured as a finished product for sale via a product manufacturing process. Cost, producibility, quality, performance, dependability, serviceability, planned lifespan, and user features are typically addressed through product engineering.
The process of constructing abstract models of a system, each model giving a distinct view or perspective of that system, is known as system modelling.
Or
A System Model is a representation of a system and its surroundings.
Or
System Modelling is a method of depicting a world perspective and a detailed view of a system using the same Graphical Notation.
The practice of creating abstract models of a system, each of which presents a different view or perspective on that system, is known as system modelling. It's all about using some type of graphical notation to represent a system, which is nearly always based on notations from the Unified Modeling Language (UML). Models assist the analyst in comprehending the system's functionality and are used to interact with consumers.
Features of a System Model
● Identify the processes that support the needs of the viewpoint in question.
● reflect the processes' behavior as well as the assumptions that the behavior is founded on.
● Clearly specify the model's exogenous and endogenous inputs.
● depict all input/output linkages that will help engineers grasp the perspective better.
System perspectives
Models can be used to understand the system from several angles:
● An external perspective in which you model the system's context or environment.
● An interaction viewpoint is one in which you represent the interactions between a system and its environment, as well as between its components.
● A structural perspective is one in which you model a system's organization or the structure of the data it processes.
● A behavioral perspective is one in which you model the system's dynamic behavior and how it reacts to events.
UML diagram types
The following are the five most useful UML diagrams for system modelling:
● Activity diagrams depict the steps in a process or the steps involved in data processing.
● Use case diagrams to depict how a system interacts with its surroundings.
● Interactions between actors and the system, as well as between system components, are depicted in sequence diagrams.
● Class diagrams depict the object classes in the system as well as the relationships between them.
● State diagrams depict how the system responds to both internal and external events.
During requirements engineering, both new and old system models are used. Models of existing systems can be used to clarify what the existing system accomplishes and to discuss its strengths and faults. As a result, requirements for the new system emerge. During requirements engineering, models of the new system are used to help explain the proposed requirements to other system stakeholders.
Context and process models
Context models are used to depict a system's operational context, or what is beyond the system's boundaries. The decision on where to place system boundaries may be influenced by social and organizational factors. The system and its relationships with other systems are depicted in architectural models.
To define what is inside and what is outside the system, system boundaries are established. They display additional systems that are used in conjunction with or rely on the system being built. The system boundary's location has a significant impact on the system's requirements. Because there may be pressures to build system boundaries that increase or lessen the influence or workload of different components of an organization, defining a system boundary is a political decision.
Context models just depict the other systems in the environment, not how the system being developed is used in it. Process models show how the built system is used in larger business operations. Business process models can be defined using UML activity diagrams.
A UML activity diagram depicting the process of involuntary detention and the role of MHC-PMS (mental healthcare patient management system) in it is shown in the example below.
Fig 5: Process model of involuntary detention
Fig 6: Context model
Interaction models
● User interaction modelling is significant because it aids in the identification of user requirements.
● Modeling system-to-system interaction shows potential communication issues.
● Understanding whether a proposed system structure is likely to produce the desired system performance and dependability is aided by modelling component interaction.
● For interaction modelling, utilize case diagrams and sequence diagrams.
Use case modeling
Use cases were created to aid in the elicitation of requirements and have now been incorporated into the UML. Each use case describes a distinct task that necessitates the use of a system from the outside. People or other systems can be actors in a use case. Diagrammatically represented to provide an overview of the use case, as well as in a more detailed textual version.
Fig 7: Simple use case diagram
Sequence diagrams
The interactions between the actors and the objects within a system are modelled using UML sequence diagrams. A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are mentioned at the top of the diagram, with a vertical dotted line traced from them. Annotated arrows show how items interact with each other.
Fig 8: Sequence diagram for Transfer Data
Structural models
Software structural models show how a system is organized in terms of the components that make it up and their relationships. Static models, which illustrate the structure of the system design, and dynamic models, which display the organization of the system while it is running, are two types of structural models. When discussing and creating the system architecture, you create structural models of the system.
When creating an object-oriented system model, UML class diagrams are used to depict the classes in the system and their relationships. An object class is a broad definition of a certain type of system object. An association is a link between classes that implies that they have some sort of relationship. Objects represent anything in the actual world while designing models in the early stages of the software engineering process, such as a patient, a prescription, a doctor, and so on.
Fig 9: Classes and associations in the MHC-PMS
Fig 10: The Consultation class
We employ generalization to deal with complexity on a daily basis. When modelling systems, it's common to look at the classes to see if there's any room for generalization. Generalization is accomplished in object-oriented languages like Java by utilizing the language's built-in class inheritance methods. The attributes and procedures associated with higher-level classes are likewise associated with lower-level classes in a generalization. The properties and activities of the superclasses are passed down to the lower-level classes, which are called subclasses. The attributes and operations of these lower-level classes are then added.
Fig 11: Generalization hierarchy with added detail
An aggregation model demonstrates how collections of classes are made up of other classes. The part-of relationship in semantic data models is related to aggregation models.
Fig 12: Aggregation association
Behavioral models
Behavioral models are representations of a system's dynamic behavior as it runs. They demonstrate what happens (or should happen) when a system responds to a stimulus from its surroundings. There are two sorts of stimuli:
● The system must process some data that has arrived.
● An event occurs that causes the system to process data. Although this is not always the case, events may contain data connected with them.
Many business systems are primarily data-driven data-processing systems. They are largely controlled by the data that is sent into the system, with only a small amount of external event processing. Data-driven models depict the steps involved in processing input data and producing the desired result. They may be used to represent end-to-end processing in a system, which is particularly valuable during requirements analysis. UML activity diagrams can be used to develop data-driven models:
Fig 13: An activity model of the insulin pump’s operation
UML sequence diagrams can also be used to develop data-driven models:
Fig 14: Sequence diagram
Key takeaway
System Modelling is a method of depicting a world perspective and a detailed view of a system using the same Graphical Notation.
Requirement engineering is the broad spectrum (variety, range) of tasks and techniques that lead to an understanding of requirements.
In other words, RE (requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.
A major software engineering operation is from a requirement engineering that starts during the communication activity and continues into the modelling activity. It needs to be customized to the requirements of the process, the project, the product and the people doing the job.
Software Requirements are a set of conditions or a capability possessed by software or system components to solve a real-world problem. The problems can be to automate a part of a system to correct shortcomings of an existing system, to control a device, and so on. IEEE defines a requirement as:
“A condition or capability needed by a user to solve a problem or achieve an objective” or “The capability possessed by a system to satisfy a contract, standard, specification, or other formally imposed documents”.
When users request for software, they possess an approximation of what the new system should be capable of doing. Requirements differ from one user to another user and from one business process to another business process. Reliability means Operational reliability.
It is described as the ability of a system or component to perform its required functions under static conditions for a specific period. It can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.
Software can be defined as a collection of programs, documentation and operating procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.
It contains seven different activities -
● Inception
● Elicitation
● Elaboration
● Negotiation
● Specification
● Validation
● Management
Elicitation
It is linked to the different ways used to obtain information and specifications about the project domain. Customers, company manuals, current applications of the same kind, specifications and other project stakeholders are among the different sources of domain information.
The methods used for the elicitation of requirements include interviews, brainstorming, mission analysis, Delphi technology, prototyping, etc. Elicitation does not generate formal models of the known specifications. Instead, it expands the analyst's domain expertise and thus helps to provide insight into the next step.
Specification
This practise is used to develop structured models of software requirements. All specifications, including both functional and non-functional requirements and limitations, are defined in their entirety by these models. More information about the issue may be needed during the specification, which can again activate the elicitation phase.
ER diagrams, data flow diagrams(DFDs), feature decomposition diagrams(FDDs), data dictionaries, etc. are the models used at this point.
Validation
It refers to a different set of tasks which ensure that customer requirements are traceable to the software that has been installed.
If specifications are not checked, errors will spread to the successive stages in the requirement descriptions, resulting in a lot of adjustment and rework.
For this method, the key steps include:
● The specifications should be compatible with all the other specifications, i.e. no two specifications should clash with each other.
● In every way, the specifications should be complete.
● The parameters should be technically feasible.
Negotiation
In the negotiating task, a software engineer decides how scarce business resources can accomplish the mission.
To build rough production guesses and access to the effect of the requirement on the cost and delivery time of the project.
The goal of this negotiation is to create a project plan that meets the needs of stakeholders while representing the real-world constraints that have been imposed on the software team (e.g. Time, personnel, budget).
The best deals pursue a "win-win" outcome. That is, by having the method or product that meets most of their needs, stakeholders win and you win by working towards practical and achievable budgets and deadlines.
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration.
Key takeaway:
The process of identifying, recording and preserving the specifications is Requirement Engineering.
It is a mechanism in which the system collects and determines the service delivered.
A method is an ordered series of operations that transforms inputs into outputs.
Descriptions of processes encapsulate information and allow reuse of it.
References:
- Software Engineering- Mishra /Mohanty (Pearson Education)
- Quantitative techniques in project management byRettyvellayudam
- Software Project Management ‐ Sanjay Mohapatra (Cengage Learning)
- Software Engineering: Theory and Practice (Fourth Edition – Pfleeger
