1. Introduction

1.1 Computer Software:

Computer software is the product that software professionals build and then support over the long term. It encompasses computer programs and associated documentation that execute within a computer of any size and architecture . Software products may be developed for a particular customer or may be developed for a general market.

Why is it important?

Software is important because it affects nearly every aspect of our lives and has become pervasive in our commerce, our culture, and our everyday activities.

• National infrastructures and utilities are controlled by computer-based systems and most electrical products include a computer and controlling software.
• Industrial manufacturing and distribution is completely computerized, as is the financial system.
• Entertainment, including the music industry, computer games, and film and television, is software intensive.

1.1.1 Software system

Software systems are abstract and intangible. They are not constrained by the properties of materials, governed by physical laws, or by manufacturing processes.

The implication of software system:
This simplifies software engineering, as there are no natural limits to the potential of software. However, because of the lack of physical constraints, software systems can quickly become extremely complex, difficult to understand, and expensive to change.

1.2 Software Failure & Success

Software engineering is criticized as inadequate for modern software development. Software failures are a consequence of two factors:

• Increasing demands
• Low expectations

1.3 Professional Software Development

• Amateur
  • People in business write spreadsheet programs to simplify their jobs.
  • Scientists and engineers write programs to process their experimental data.
  • Hobbyists write programs for their own interest and enjoyment.
• Professional
  • developed for specific business purposes, for inclusion in other devices, or as software products.
  • Intended for use by someone apart from its developer.
  • It is usually developed by teams rather than individuals.
  • It is maintained and changed throughout its life.

Software engineering is intended to support professional software development, rather than individual programming. It includes techniques that support program specification, design, validation, and evolution. Professional software usually has the following properties:

• Strict user requirements
• Required accuracy and data integrity
• Higher security standard
• Stable performance for heavy load
• Required technical support, etc.

Some product characteristics:

1. Maintainability: Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment.
2. Dependability and Security: Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system.
3. Efficiency: Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc.
4. Acceptability: Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable, and compatible with other systems that they use.

Two kinds of software products

• Generic software products: These are systems that are produced by a development organization and sold on the open market to any customer who is able to buy them.
• Customized software products: These are systems that are commissioned by a particular customer. A software contractor develops the software especially for that customer.

1.4 Software Deterioration

Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”

Software doesn’t wear out. But it does deteriorate. During its life, software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve”

Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again.

1.5 Software Engineering

Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use.

Engineering discipline
Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constraints.

All aspects of software production
Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software roduction.

Why software engineering important?
More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use.

1.5.1 Software Engineering Approaches

The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product.

There are four fundamental activities that are common to all software processes:

1. Software specification
2. Software development
3. Software validation
4. Software evolution

1.5.2 General Issues That Affect Most Software

• Heterogeneity: Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.
• Business and social change: Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software.
• Security and trust: As software is intertwined with all aspects of our lives, it is essential that we can trust that software.

1.5.3 Software Engineering Diversity

Different types of systems need different development processes. Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers.

Two major approaches:

• Sequential
• Iterative

Application Types

1. Stand-alone applications: These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network.
2. Interactive transaction-based applications: Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications.
3. Embedded control systems: These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system.
4. ** Batch processing systems:** These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs.
5. Entertainment systems: These are systems that are primarily for personal use and which are intended to entertain the user.
6. Systems for modeling and simulation: These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects.
7. Data collection systems: These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing.
8. Systems of systems: These are systems that are composed of a number of other software systems.

1.5.4 Software Engineering Fundamentals

Some fundamental principles apply to all types of software system, irrespective of the development techniques used:

• Systems should be developed using a managed and understood development process. Of course, different processes are used for different types of software.
• Dependability and performance are important for all types of system.
• Understanding and managing the software specification and requirements (what the software should do) are important.
• Where appropriate, you should reuse software that has already been developed rather than write new software.

1.5.5 Software Engineering and The Web

The Web is now a platform for running application and organizations are increasingly developing web-based systems rather than local systems.

Web services allow application functionality to be accessed over the web. Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’.

Software reuse is the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from pre-existing software components and systems.

Web-based systems should be developed and delivered incrementally. It is now generally recognized that it is impractical to specify all the requirements for such systems in advance.

User interfaces are constrained by the capabilities of web browsers. Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. Web forms with local scripting are more commonly used.

Web-based systems are complex distributed systems but the
fundamental principles of software engineering discussed
previously are as applicable to them.

1.5.6 Software Engineering Ethics

Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of people working in that area.

As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills. You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer. You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession.

There are areas where standards of acceptable behavior are not bound by laws but by the more tenuous notion of professional responsibility. Some of these are:

• Confidentiality
• Competence
• Intellectual property rights
• Computer misuse

1.5.7 Software Development Risk

Many software development projects run into difficulties

• Does not work as expected
• Over budget
• Late delivery

Much of the functionalities in the software is wasted

• Wrong requirement
• User dislike it
• There are no customer

Many software projects fail because the software developers build the wrong software. The software development team must:

• Fully understand requirement
• Validate requirement

The developer will often add technical insights and suggestions, but remember the client satisfaction is the primary measurement of success in software project.

How to minimize risk
Communication with the client

• Feasibility studies
• Separation of requirement from design
• Milestones and releases
• Acceptance and user testing

---

2. Software process models

A software process model is a simplified representation of a software process. Discuss very general process models and present these from an architectural perspective, framework of the process rather than the details of specific activities.

These generic models are not definitive descriptions of software processes, they are abstractions of the process that can be used to explain different approaches to software development.

2.1 The waterfall model

This takes the fundamental process activaties of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.

Because of the cascade from one phase to another, this model is known as the ‘waterfall model’ or software life cycle. The waterfall model is an example of a plan-driven process.

In principle, the result of each phase is one or more documents that are approved (‘signed off’). The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. The software process is not a simple linear model but involves feedback from one phase to another. Documents produced in each phase may then have to be modified to reflect the changes made.

Because of the costs of producing and approving documents, iterations can be costly and involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as the specification, and to continue with the later development stages. Problems are left for later resolution, ignored, or programmed around. This premature freezing of development tasks may mean that the system won’t deliver what the users are expecting.

During the final life cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.

Advantages

• In the Waterfall Model, documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan.

Drawbacks

• Its major problem is the inflexible partitioning of the project into distinct stages.
• Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.

Summary
In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development.

2.2 Incremental development

This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.

Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed. Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities. Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e-commerce, and personal systems.

By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed. Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments.

Incremental development has three important benefits, compared to the waterfall model:

• The cost of accommodating changing customer requirements is reduced.
• It is easier to get customer feedback on the development work that has been done.
• More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included.

From a management perspective, the incremental approach has two problems:

• The process is not visible.
• System structure tends to degrade as new increments are added.
• large organizations have bureaucratic procedures that have evolved over time and there may be a mismatch between these procedures and a more informal iterative or agile process.
• Formal procedures are required by external regulations (e.g., accounting regulations)

Summary
The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system.

Large systems need a stable framework or architecture and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture.

This has to be planned in advance rather than developed incrementally.

2.3 Reuse-oriented software engineering

This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.

In the majority of software projects, there are some forms of informal software reuse. This informal reuse takes place irrespective of the development process that is used. In the 21st century, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a large base of reusable software components and an integrating framework for the composition of these components.

There are three types of software component that may be used in a reuse-oriented process:

• Web services that are developed according to service standards and which are available for remote invocation.
• Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
• Stand-alone software systems that are configured for use in a particular environment.

Adavantages

• reducing the amount of software to be developed and so reducing cost and risks.
• usually also leads to faster delivery of the software.

Drawbacks

• Requirements compromises are inevitable, and this may lead to a system that does not meet the real needs of users.
• Some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.

---

3. Software process activities

Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system.

The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence. In incremental development they are interleaved. How these activities are carried out depends on the type of software, people, and organizational structures involved.

3.1 Software Specification

Software specification or requirements engineering is the process of understanding and defining

• what services are required from the system
• identifying the constraints on the system’s operation and development.

Requirements engineering is a particularly critical stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation.

There are four main activities in the requirements engineering process:

The requirements engineering process aims to produce an agreed requirements document that specifies a system satisfying takeholder requirements.

Requirements are usually presented at two levels of detail:

• End-users and customers need a high-level statement of the requirements
• system developers need a more detailed system specification.

3.2 Software design and implementation

The implementation stage of software development is the process of converting a system specification into an executable system.

It always involves processes of software design and programming but, if an incremental approach to development is used, may also involve refinement of the software pecification.

A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

Design activities

• Architectural design: where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed.
• Interface design: where you define the interfaces between system components. This interface specification must be unambiguous.
• Component design: where you take each system component and design how it will operate.
  • a simple statement of the expected functionalities
  • a list of changes to be made to a reusable component
  • a detailed design model (model-driven approach).
• Database design: where you design the system data structures and how these are to be represented in a database.

Designers do not arrive at a finished design immediately but develop the design iteratively. They add formality and detail as they develop their design with constant backtracking to correct earlier designs.

The detail and representation of the design output vary considerably.

• For critical systems, detailed design documents setting out precise and accurate descriptions of the system must be produced.
• If a model-driven approach is used, these outputs may mostly be diagrams.
• Where agile methods of development are used, the outputs of the design process may not be separate specification documents but may be represented in the code of the program.
• Model-driven development (MDD) or model-driven engineering (Schmidt, 2006), where models of the software are created at different levels of abstraction
• The models are developed in sufficient detail so that the executable system can be generated from them
• Software development tools may be used to generate a skeleton program from MDD. This includes code to define and implement interfaces, and, in many cases, the developer need only add details of the operation of each program component

3.3 Software validation

Software validation or, more generally, verification and validation (V&V) is intended to show that

• a system both conforms to its specification
• it meets the expectations of the system customer

Program testing, where the system is executed using simulated test data, is the principal validation technique.

Validation may also involve checking processes, such as
inspections and reviews, at each stage of the software process
from user requirements definition to program development.

A three-stage testing process involved testing for system components then the testing for an integrated system and, finally, the testing of the system with the customer’s data

The stages in the testing process are:

• Development testing: The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components.
• System testing: System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems.
• Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than with simulated test data.

Normally, component development and testing processes are interleaved. Programmers make up their own test data and incrementally test the code as it is developed.

If an incremental approach to development is used, each increment should be tested as it is developed, with these tests based on the requirements for that increment.

When a plan-driven software process is used (e.g., for critical systems development), testing is driven by a set of test plans. An independent team of testers works from these pre-formulated test plans.

3.4 Software evolution

Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design. However, changes can be made to software at any time during or after the system development. Even extensive changes are still much cheaper than corresponding changes to system hardware

Historically, there has always been a split between the process of software development and the process of software evolution (software maintenance)

People think of software development as a creative activity in which a software system is developed from an initial concept through to a working system. However, they sometimes think of software maintenance as dull and uninteresting

Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process

---

4. Agile methods

4.1 Rapid software development

The software is not developed as a single unit but as a series of increments, with each increment including new system functionality.

Fundamental characteristics:

• The processes are interleaved.
• Minimum documentation
• Developed in a series of versions, or increments, with system stakeholders involvement.
• System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created

Other approaches to RAD includes:

• Adaptive software development
• Agile methodologies
• Spiral model
• Unified software development process

4.2 Plan-driven development approach

Large, long lived software - careful project planning, formalized quality assurance, the use of analysis and design methods supported by CASE tools, and controlled and rigorous software development processes.

• Work of multiple development teams has to be well coordinated
• The system is a critical system. A critical system is a system that refers to the systems that are efficient and retain this efficiency as they change without prohibitive costs being incurred.
• Many different people will be involved in maintaining the software over long period of time

4.3 Agile methods

• Agile allowed the development team to focus on the software itself rather than on its design and documentation.
• universally rely on an incremental approach to software specification, development, and delivery.
• They are best suited to application development where the system requirements usually change rapidly during the development process
• They are intended to deliver working software quickly to customers, who can then propose new and changed requirements to be included in later iterations of the system.
• The philosophy behind agile methods is reflected in the agile manifesto that was agreed on by many of the leading developers of these methods.
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Principle

• Customer involvement: Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.
• Incremental delivery: The software is developed in increments with the customer specifying the requirements to be included in eacch increment.
• People not process: The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.
• Embrace change: Expect the system requirements to change and so design the system to accommodate these changes.
• Maintain simplicity: Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

Some of the agile methods:

• Extreme programming (Beck, 1999; Beck, 2000)
• Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001)
• Crystal (Cockburn, 2001; Cockburn, 2004)
• Adaptive Software Development (Highsmith, 2000)
• DSDM (Stapleton, 1997; Stapleton, 2003)
• Feature Driven Development (Palmer and Felsing, 2002)

These agile methods are all based around the notion of incremental development and delivery with different processes. However, they share a set of principles, based on the agile manifesto, and so have much in common.

The Challenges

• In practice, the principles underlying agile methods are sometimes difficult to realize:
  • Its success depends on having a customer who is willing and able to spend time with the development team and who can represent all system stakeholders
  • Individual team members may not have suitable personalities for the intense involvement
  • Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders
  • Maintaining simplicity requires extra work
  • It is difficult for some organization to accept informal processes defined by development teams
• The software requirements document is usually part of the contract between the customer and the supplier (software company)
• Because incremental specification is inherent in agile methods, writing contracts for this type of development may be difficult.
• Agile methods have to rely on contracts in which the customer pays for the time required for system development rather than the development of a specific set of requirements
• Agile methods have to rely on contracts in which the customer pays for the time required for system development rather than the development of a specific set of requirements

Maintenance

• There are two questions that should be considered when considering agile methods and maintenance:
  • Are systems that are developed using an agile approach maintainable, given the emphasis in the development process of minimizing formal documentation?
  • Can agile methods be used effectively for evolving a system in response to customer change requests?
• Formal documentation is supposed to ease system evolution and maintenance. In practice, however, formal documentation is often not kept up to date and so does not in system maintainability
• Agile methods supporters argue that it is a waste of time to write this out-of-date documentation
• The key to implementing maintainable software is to produce high-quality, readable code.
• The key document is the system requirements document, which tells the
  software engineer what the system is supposed to do.
• The main difficulty after software delivery is likely to be keeping customers involved in the process.
• The other problem that is likely to arise is maintaining continuity of the development team. Agile methods rely on team members understanding aspects of the system without having to consult documentation.
• If an agile development team is broken up, then this implicit knowledge is lost and it is difficult for new team members to build up the same nderstanding of the system and its components.

Plan-driven and agile development

Most software projects include practices from plan-driven and agile approaches. To decide on the balance between a plan-based and an agile approach, you have to answer a range of technical, human, and organizational questions:

• Detail specification and design needed?
• Is incrementally strategy realistic?
• How large is the system?
• what type of system being developed?
• System life span?
• Available technologies and tools?
• Organization of the team?
• Cultural issues?
• Available skillsets?
• External regulation?

---

5. Scrum Framework

5.1 Scrum Roles

• Scrum development efforts consist of one or more Scrum teams
• Each made up of three Scrum roles: product owner, ScrumMaster, and the development team
  • The product owner is responsible for what will be developed and in what order
    • The single authority responsible for deciding which features and functionality to build and the order in which to build them
    • The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve
    • The product owner is responsible for the overall success of the solution being developed or maintained.
    • To make sure that the most valuable work is always performed
    • The product owner actively collaborates with the ScrumMaster and development team
    • Must be available to answer questions soon after they are posed
  • The Scrum Master is responsible for guiding the team in creating and following its own process based on the broader Scrum framework
    • Helps everyone involved understand and embrace the Scrum values, principles, and practices
    • Acts as a coach, providing process leadership and helping the Scrum team and the rest of the organization develop their own high performance, organization-specific Scrum approach
    • The ScrumMaster helps the organization through the challenging change management process that can occur during a Scrum adoption.
    • As a facilitator, the ScrumMaster helps the team resolve issues and make improvements to its use of Scrum
    • Also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity
    • The ScrumMaster has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager (The ScrumMaster functions as a leader, not a manager)
  • The development team is responsible for determining how to deliver what the product owner has asked for
    • Scrum defines the role of a development team, which is simply a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product
    • The development team self-organizes to determine the best way to accomplish the goal set out by the product owner
    • The development team is typically five to nine people in size
    • Its members must collectively have all of the skills needed to produce good quality, working software
    • For development efforts that require much larger team size, team members can be organized into several teams with each team nine or fewer team members

5.2 Scrum Activities and Artifacts

Product Backlog:

• The product owner, with input from the rest of the Scrum team and stakeholders, is ultimately responsible for determining and managing the sequence of works (product backlog items) and communicating it in the form of a prioritized (or ordered) list known as the product backlog
• On new-product development the product backlog items initially are features required to meet the product owner’s vision.
• For ongoing product development, the product backlog might also contain new features, changes to existing features, defects needing repair, technical improvements, and so on.
• Product owner collaborates with internal and external stakeholders to gather and define the product backlog items
• High-value items appear at the top of the product backlog and the lower-value items appear toward the bottom.
• The product backlog is a constantly evolving artifact. Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows
• In practice, many teams use a relative size measure such as story points or ideal days to express the item size

Product Backlog Grooming: The activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming

Sprint:

• In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints
• The work completed in each sprint should create something of tangible value to the customer or user
• Sprints are timeboxed so they always have a fixed start and end date, and generally
• They should all be of the same duration
• A new sprint immediately follows the completion of the previous sprint

Sprint Planning:

• During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve
• Based on the sprint goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace
• Many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog
• The team provides an estimate (typically in hours) of the effort required to complete each task

Sprint Execution:

• Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team performs all of the task-level work necessary to get the features done
• “done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed.
• Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal

Daily Scrum:

• Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum
• This inspect-and-adapt activity is sometimes referred to as the daily stand-up because of the common practice of everyone standing up during the meeting to help promote brevity
• ScrumMaster facilitating and each team member taking turns answering three questions:
  • What did I accomplish since the last daily scrum?
  • What do I plan to work on by the next daily scrum?
  • What are the obstacles or impediments that are preventing me from making progress?
• The purpose is for everyone to understands the big picture of what is occurring, how they are progressing toward the sprint goal, any modifications they want to make to their plans for the upcoming day’s work, and what issues need to be addressed.
• Not a problem-solving activity
• Talk about problems after the daily scrum and do so with a small group of interested member
• Not a traditional status meeting
• Communicate the status of sprint backlog items among the development team members
• It is an inspection, synchronization, and adaptive daily planning activity that helps a self-organizing team do its job better.

Sprint Review:

• At the end of the sprint there are two additional inspect-and-adapt activities, sprint review and sprint retrospective
• Sprint review is to inspect and adapt the product that is being built.
• Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers, and interested members of other teams.
• Focused on reviewing the just-completed features in the context of the overall development effort.
• Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.

Sprint Retrospective

• The second inspect-and-adapt activity at the end of the sprint
• Frequently occurs after the sprint review and before the next sprint planning
• Sprint retrospective is an opportunity to inspect and adapt the process
• The development team, ScrumMaster, and product owner discuss what is and is not working with Scrum and associated technical practices.
• The focus is on the continuous process improvement
• At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions

Definition of Done

• sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed-upon definition of done
• This definition specifies the degree of confidence that the work completed is of good quality and is potentially shippable.
• A bare-minimum definition of done should yield a complete slice of product functionality that is designed, built, integrated, tested, and documented
• “potentially shippable” does not mean that what got built must actually be shipped.
• Shipping is a business decision, which is frequently influenced by things such as:
  • Do we have enough features or enough of a customer workflow to justify a customer deployment?
  • Can our customers absorb another change given that we just gave them a release two weeks ago?

---

6. Requirements Engineering

6.1 User requirements and system requirements

High-level description and detail description
As part of a contract for a large software development project, it must define its needs in a sufficiently abstract way. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do.

• User requirements: Statements in a natural language plus diagrams to describe the services and constraint of a system.
• System requirements: More detailed descriptions of the software system’s functions, services, and operational constraints.

Requirements should state what the system should do and the design should describe how it does this.

6.2 Functional & Non-functional requirements

Software system requirements are often classified as functional requirements or nonfunctional requirements

6.2.1 Functional requirements

These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do.

When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. More specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.

The functional requirements specification of a system should be both complete and consistent.

• Completeness means that all services required by the user should be defined.
• Consistency means that requirements should not have contradictory definitions.

6.2.2 Non-functional requirements

These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.

Often more critical than individual functional requirements failing to meet a non-functional requirement can mean that the whole system is unusable

The implementation of non-functional requirements may be intricately dispersed throughout the system. They may affect the overall architecture of a system rather than the individual components. A single non-functional requirement may generate a number of related functional requirements.

• Product requirements: These requirements specify or constrain the bahavior of the software.
• Organizational requirements: These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization.
• External requirements: This broad heading cover all requirements that are derived from factors external to the system and its development process.

A common problem with non-functional requirements is that users or customers often propose these requirements as general goals

Non-functional requirements often conflict and interact with other functional or non-functional requirements. It is difficult to separate functional and non-functional requirements in the requirements document.

6.3 The Software requirements document

The software requirements document (software requirements specification or SRS) is an official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirement.

Requirements documents are essential when an outside contractor is developing the software system.

Agile development methods argue that requirements change so rapidly that a requirements document is out of date as soon as it is written. But it is still useful to write a short supporting document that defines the business and dependability requirements for the system

Level of Details
The level of detail that you should include in a requirements document depends on the type of system that is being developed and the development process used.

• Detailed requirements
  • Critical systems.
  • system is to be developed by a separate company.
• Less detailed requirements
  • inhouse
  • iterative development process.

6.4 Requirements egineering processes

• Feasibility study: assessing if the system is useful to the business
• Elicitation and analysis: discovering requirements
• Specification: converting these requirements into some standard form.
• Validation: checking that the requirements actually define the system that the customer wants.

6.5 Requiremets elicitation and analysis

software engineers work with customers and system end-users to find out about:

• the aplication domain
• what services the system should provide
• the required performance of the system
• hardware constrains

may involve a variety of different kinds of people in an organization include:

• end users who will interact with the system
• anyone else in an organization who will be affected by it.
• engineers who are developing or maintaining other related systems
• business managers
• domain experts
• trade union representatives.

Requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities.

• Requirements discovery: This is the process of interacting with stakeholders of the system to discover their requirements.
• Requirements classification and organization: This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. (Using a model of the system architecture to identify sub-systems and to associate requirements with each sub-system)
• Requirements prioritization and negotiation: When multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation.
• Requirements specification: The requirements are documented and input into the next round of the spiral.

6.5.1 Challenges

Eliciting and understanding requirements from system stakeholders is a difficult process for several reasons:

• Stakeholders often don’t know what they want from a computer system except in the most general terms; they may find it difficult to articulate the requirements; they may make unrealistic demands because they don’t know what is and isn’t feasible
• Stakeholders in a system express requirements in their own terms and with implicit knowledge of their own work.
• Different stakeholders have different requirements and priorities, and they may express these in different ways, some of these requirements have commonalities and conflict.
• Political factors may influence the requirements of a system.
• The economic and business environment in which the analysis takes place is dynamic. It changes during the analysis process.

6.5.2 Requirements Discovery

Requirements discovery (requirements elicitation) is the process of gathering information about the required system and existing systems, and distilling the user and system requirements from this information.

requirements may also come from the application domain and from other systems that interact with the system

methods:

1) Interview

1. Formal or informal interviews with system stakeholders.
2. The requirements engineering team puts questions to stakeholders about the system that they currently use and the system to be developed.
3. Requirements are derived from the answers to these questions.

• Closed interviews: Where the stakeholder answers a pre-defined set of questions.
• Open interviews: no pre-defined agenda. The requirements engineering team explores a range of issues with system stakeholders.

Interviews are good for:

• getting an overall understanding of what stakeholders do
• how they might interact with the new system
• the difficulties that they face with current systems

It can be difficult to elicit domain knowledge through interviews for two reasons:

• All application specialists use terminology and jargon that are specific to a domain. They normally use terminology in a precise and subtle way that is easy for requirements engineers to misunderstand.
• Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn’t worth mentioning

Drawbacks: Not an effective technique for eliciting knowledge about organizational requirements and constraints because there are subtle power relationships between the different people in the organization. most people are generally reluctant to discuss political and organizational issues that may affect the requirements

Effective interviewers have two characteristics:
They are open-minded, avoid pre-conceived ideas about the requirements, and are willing to listen to stakeholders. They prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a rototype system.

2) Scenarios
System user can understand and criticize a scenario of how they might interact with a software system. Use the information gained from the discussion based on a scenario to formulate the actual system requirements. A scenario is the descriptions of example interaction sessions. Each scenario usually covers one or a small number of possible interactions. A scenario starts with an outline of the interaction. During the elicitation process, details are added to this to create a complete description of that interaction.

Scenario-based elicitation involves working with stakeholders to identify scenarios and to capture details to be included in these scenarios. Scenarios may be written as text, supplemented by diagrams, screen shots, etc. Alternatively, a more structured approach such as event scenarios or use cases may be used.

use cases
Use cases are a requirements discovery technique. In their simplest form, a use case identifies the actors involved in an interaction and names the type of interaction. It is supplemented by additional information describing the interaction with the system. (Textual description and one or more graphical models)

Use cases are documented using a high-level use case diagram. The set of use cases represents all of the possible interactions that will be described in the system requirements.

Drawbacks: Use case focus on interactions with the system, they are not as effective for eliciting:

• constrains
• high-level business
• non-functional requirements
• domain requirements

3) Ethnography
Systems are used in a social and organizational context and software system requirements may be derived or constrained by that context. Satisfying these social and organizational requirements is often critical for the success of the system. Ethnography is an observational technique that can be used to understand operational processes and help derive support requirements for these processes. An analyst immerses himself or herself in the working environment to observe the actual tasks in which participants are involved.

Advantages: Ethnography is particularly effective for discovering two types of requirements:

• Requirements that are derived from the way in which people actually work, rather than the way in which process definitions say they ought to work.
• Requirements that are derived from cooperation and awareness of other people’s activities.

Drawbacks: Ethnography focuses on the end-user, this approach:

• is not always appropriate for discovering organizational or domain requirements.
• cannot always identify new features that should be added to a system

6.5.3 Requirements Specification

The process of writing down the user and system requirements in a requirements document. The user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. Stakeholders interpret the requirements in different ways and there are often inherent conflicts and inconsistencies in the requirements. The user requirements for a system should describe the functional and non-functional requirements in a way they are understandable by system users who don’t have detailed technical knowledge

• Specify only the external behavior of the system.
• Should not include details of the system architecture or design
• Write user requirements in natural language, with simple tables, forms, and intuitive diagrams.
• System requirements are expanded versions of the user requirements
• They add detail and explain how the user requirements should be provided by the system
• They may be used as part of the contract for the implementation of the system

it is practically impossible to exclude all design information. There are several reasons for this:

• You may have to design an initial architecture of the system to help structure the requirements specification. The system requirements are organized according to the different sub-systems that make up the system.
• Systems may interoperate with existing systems, which constrain the design and impose requirements on the new system.
• The use of a specific architecture to satisfy non-functional requirements may be necessary.

To minimize misunderstandings when writing natural language requirements:

• Invent a standard format and ensure that all requirement definitions adhere to that format. Standardizing the format makes omissions less likely and requirements easier to check
• Use language consistently to distinguish between mandatory and desirable requirements
• Use text highlighting to pick out key parts of the requirement.
• Do not assume that readers understand technical software engineering language.
• Associate a rationale with each user requirement. The rationale should explain why the requirement has been included

user requirements can be written on cards, one requirement per card. A number of fields on each card (requirements rationale, dependencies on other requirements, the source of the requirements, supporting materials)

6.5.4 Requirements validation

Requirements validation is the process of checking that requirements actually define the system that the customer really wants. It is important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service.

During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include:

• Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
• Consistency checks: Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function.
• Completeness checks: The requirements document should include requirements that define all functions and the constraints intended by the system user.
• Realism checks: Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented.
• Verifiability: To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable.

methods:

1. Requirements reviews: The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies
2. Prototyping: In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers
3. Test-case generation: Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems

---

7. System Modeling

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system.

System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML).

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

Existing and planned system models
Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system.

Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation.

In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model.

System perspectives

• An external perspective, where you model the context or environment of the system.
• An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system.
• A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

UML diagram types

• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between system components.
• Class diagrams, which show the object classes in the system and the associations between these classes.
• State machine diagrams, which show how the system reacts to internal and external events.

Use of graphical models

• As a means of facilitating discussion about an existing or proposed system
  • Incomplete and incorrect models are OK as their role is to support discussion.
• As a way of documenting an existing system
  • Models should be an accurate representation of the system but need not be complete.
• As a detailed system description that can be used to generate a system implementation
  • Models have to be both correct and complete.

7.1 Context models

• Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.
• Social and organisational concerns may affect the decision on where to position system boundaries.
• Architectural models show the system and its relationship with other systems.
• System boundaries are established to define what is inside and what is outside the system.
  • They show other systems that are used or depend on the system being developed.
• The position of the system boundary has a profound effect on the system requirements.
• Defining a system boundary is a political judgment
  • There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization.
• Context models simply show the other systems in the environment, not how the system being developed is used in that environment.
• Used along with other models, such as business process models.
• UML activity diagrams may be used to define business process models.

7.2 Interaction models

• Modeling user interaction is important as it helps to identify user requirements.
• Modeling system-to-system interaction highlights the communication problems that may arise.
• Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability.
• Use case diagrams and sequence diagrams may be used for interaction modeling.

Use case diagram

• Use case diagrams and sequence diagrams may be used for interaction modeling.
• Each use case represents a discrete task that involves external interaction with a system.
• Actors in a use case may be people or other systems.
• Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

Sequence diagrams

• Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system.
• 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 listed along the top of the diagram, with a dotted line drawn vertically from these.
• Interactions between objects are indicated by annotated arrows.

7.3 Structural models

• Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
• Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing.
• You create structural models of a system when you are discussing and designing the system architecture.

Class diagrams

• Class diagrams are used when developing an objectoriented system model to show the classes in a system and the associations between these classes.
• An object class can be thought of as a general definition of one kind of system object.
• An association is a link between classes that indicates that there is some relationship between these classes.
• When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

7.4 Behavioral models

Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment.

You can think of these stimuli as being of two types:

• Data: Some data arrives that has to be processed by the system.
• Events: Some event happens that triggers system processing. Events may have associated data, although this is not always the case.

Data-driven modeling

• Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing.
• Data-driven models show the sequence of actions involved in processing input data and generating an associated output.
• They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system.
• Activity diagram and sequence diagram are used in data-driven modeling

Event-driven modeling

• Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone.
• Event-driven modeling shows how a system responds to external and internal events.
• It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.

State machine diagram

• These model the behaviour of the system in response to external and internal events.
• They show the system’s responses to stimuli so are often used for modelling real-time systems.
• State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
• Statecharts are an integral part of the UML and are used to represent state machine models.

7.5 Model-driven engineering

Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process.

The programs that execute on a hardware/software platform are then generated automatically from the models.

Proponents of MDE argue that this raises the level of abstraction in software engineering so that engineers no longer have to be concerned with programming language details or the specifics of execution platforms.

Model-driven engineering is still at an early stage of development, and it is unclear whether or not it will have a significant effect on software engineering practice.

Pros:

• Allows systems to be considered at higher levels of abstraction
• Generating code automatically means that it is cheaper to adapt systems to new platforms.

Cons:

• Models for abstraction and not necessarily right for implementation.
• Savings from generating code may be outweighed by the costs of developing translators for new platforms.

7.5.1 Model driven architecture

Model-driven architecture (MDA) was the precursor of more general model-driven engineering.

MDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system.

Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

Types of model

• A computation independent model (CIM): These model the important domain abstractions used in a system. CIMs are sometimes called domain models.
• A platform independent model (PIM): These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events.
• Platform specific models (PSM): These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

Agile methods and MDA

• The developers of MDA claim that it is intended to support an iterative approach to development and so can be used within agile methods.
• The notion of extensive up-front modeling contradicts the fundamental ideas in the agile manifesto and I suspect that few agile developers feel comfortable with model driven engineering
• If transformations can be completely automated and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process as no separate coding would be required.

Executable UML
The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible.

To create an executable subset of UML, the number of model types has therefore been dramatically reduced to these 3 key types:

• Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
• Class models in which classes are defined, along with their attributes and operations.
• State models in which a state diagram is associated with each class and is used to describe the life cycle of the class

The dynamic behavior of the system may be specified declaratively using the object constraint language (OCL), or may be expressed using UML’s action language.

Key points

• A model is an abstract view of a system that ignores systemdetails. Complementary system models can be developed to show the system’s context, interactions, structure and behavior
• Context models show how a system that is being modeled is positioned in an environment with other systems and processes.
• Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
• Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.
• Behavioral models are used to describe the dynamic behavior of an executing system. This behavior can be modeled from the perspective of the data processed by the system, or by the events that stimulate responses from a system.
• Activity diagrams may be used to model the processing of data, where each activity represents one process step.
• State diagrams are used to model a system’s behavior in response to internal or external events.
• State diagrams are used to model a system’s behavior in response to internal or external events.

7.6 Use Case Diagram

• A picture
• describes how actors relate to use cases
• use cases relate to one another
• Diagrams are not essential. They are helpful in giving an overview, but only secondary in importance to the textual description
• They do not capture the full information of the actual use cases
• In contrast, text is essential

Use Case Diagram Objective
Built in early stages of development.

• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts and domain experts

7.6.1 Actor

Include all user roles that interact with the system. Include system components only if they responsible for initiating / triggering a use case.

• primary: a user whose goals are fulfilled by the system
  • importance: define user goals
• supporting: provides a service to the system
  • importance: clarify external interfaces and protocols
• offstage: has an interest in the behavior but is not primary or supporting, e.g., government
  • importance: ensure all interests (even subtle) are identified and satisfied

Finding Actors
External objects that produce/consume data:

• Must serve as sources and destinations for data
• Must be external to the system

7.6.2 Use Case

• System function (process: automated or manual)
• Named by verb.
• Each Actor must be linked to a use case, while some use cases may not be linked to actors.
  

Linking Use Cases

• Include
• Extend
• Association
• Generalization: One element (child) is based on another element (parent)
  

7.7 Sequence Diagram

• Describe the flow of messages, events, actions between objects
• Show concurrent processes and activations
• Show time sequences that are not easily depicted in other diagrams
• Typically used during analysis and design to document and understand the logical flow of your system

Emphasis on time ordering.

• participant: object or entity that acts in the diagram – diagram starts with an unattached “found message” arrow
• message: communication between participant objects
• axes:
  • horizontal: which object/participant is acting
  • vertical: time (down -> forward in time)

Representing Objects
Squares with object type, optionally preceded by “name :”

• write object’s name if it clarifies the diagram
• object’s “life line” represented by dashed vert. line
• Name syntax: <objectname>:<classname>

Messages Between Objects
messages (method calls) indicated by arrow to other object

• write message name and arguments above arrow
• dashed arrow back indicates return
• different arrowheads for normal / concurrent (asynchronous) calls

Indicating method calls
activation: thick box over object’s life line; drawn when object’s method is on the stack

• either that object is running its code, or it is on the stack waiting for another object’s method to finish
• nest activations to indicate recursion

Selection and loops
box around part of diagram to indicate if or loop

Why not just code it?

• a good sequence diagram is still a bit above the level of the real code (not all code is drawn on diagram)
• sequence diagrams are language-agnostic (can be implemented in many different languages
• non-coders can do sequence diagrams
• easier to do sequence diagrams as a team
• can see many objects/classes at a time on same page (visual bandwidth)

7.8 Class Model / Domain Model

Illustrates meaningful conceptual classes in problem domain. Represents real-world concepts, not software components

Why domain model?

• Gives a conceptual framework of the things in the problem space
• Helps you think – focus on semantics
• It is a static view - meaning it allows us convey time invariant business rules
• Foundation for modelling
• Based on the defined structure, we can describe the state of the problem domain at any time.

Features

• Domain classes: each domain class denotes a type of object.
• Attributes: an attribute is the description of a specified type in a domain class; each instance of the class separately holds a value.
• Associations: an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship.

Steps to Create a Domain Model

1. Identify candidate conceptual classes
   • Identify, classify, and define objects, ideas, and events as Classes by examining the usage scenarios developed in the use case model, glossary, and other diagrams.
     • Reuse an existing domain model
     • Use a conceptual class category list
     • Identify noun phrases
       • Classes are determined by underlining each noun or noun phrase and entering it into a simple table.
       • Synonyms should be noted. Beware of ambiguity.
       • If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space
   • Use six selection characteristics to select classes for the analysis model
     • Retained information: if information about the class must be remembered so that the system can function
     • Needed services: the potential class must have a set of identifiable operation that is needed by the system to operate
     • Multiple attributes: a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity
     • Common attributes: A set of attributes can be defined for the potential class and these attributes apply to all instances of the class.
     • Common operations: A set of operations can be defined for the potential class and these operations apply to all instances of the class.
     • Essential requirements: External entities that appear in the problem space and produce or consume information essential to the operation of the system
2. Draw them in a UML as a Class Diagram
3. Add associations necessary to record the relationships that must be retained. Association is the relationship between 2 separate classes.
   • Association can be further defined to indicate multiplicity.
   • Multiplicity indicate the number of instances exist in an association
   • Use verbs as the Association Name
   • Use arrow to aid the reading of the Association Name
   • Composition and Aggregation are the two forms of association (object made up of another object).
4. Add attributes necessary for information to be preserved
   • Attributes describe an object
   • Study use case to select the attribute belonging to a particular class
   • Some of the attributes are the compounded attribute that you may or may not want to break it down to elementary attributes, and vice versa.
   • In the modeling for requirement analysis, data type and access scope of the attributes are not required
   • Operations define the behavior of an object.
   • 4 broad categories. Operations that
     • manipulate data
     • perform computation
     • inquire about the state of an object
     • Monitor an object for the occurrence of event
   • Operations act on class attributes and/or associations
   • examining the usage scenarios developed in the use case model. Verbs used in the scenario is the potential operations for classes.
   • Decisions on which operations should each classes be responsible is the concern in the design phrase
   • Design concept involving modularity and coupling

7.9 Activity Diagram

An activity represents an operation, a step in a business process, or an entire business process. Action is a named element which represents a single atomic step within activity i.e. that is not further decomposed within the activity. Arrow represents the transition from one activity to the next. Filled circle represent start, bull’s eye represent an endpoint

Decision
Label the condition with a squared bracket

Concurrent Paths
When two or more concurrent paths running at the same time. Use solid bold line to split the transition arrow into multiple concurrently executing paths. Solid bold line also used to merge the concurrent paths

Sending and Receiving Signal
There will be situation when your process need to send or receive signal. Convex polygon – sending signal / output event. Concave polygon – receiving signal / input event

Swimlanes
Use swimlanes to show who responsible for each activity in a process. Separate the diagram into parallel segments called swimlanes. Each swimlane shows the name of a role at the top. Transitions can take place from one swimlane to another

Flow Final Node
Not Activity Final Node. UML 2.0 has an additional control node type called Flow Final that is used as an alternative to the Activity Final node to terminate a flow. It is needed because in UML 2.0, when control reaches any instance of Activity Final node, the entire activity (including all flows) is terminated. The Flow Final simply terminates the flow to which it is attached.

Time Event

7.10 Behavior-based Model

dynamic behavior of the system. function of specific events and time; indicates how software will respond to external events or stimuli

Creating a Behavioral Model

1. evaluate all use cases to fully understand the sequence of interaction within the system
2. identify events that drive the interaction sequence and understand how these events relate to specific objects
   • Scenarios in use case description represent sequence of activities that involves actors and the system
   • The actor and the system exchange information in the sequence of activities
   • The exchange of information is an event.
   • Some event have an explicit impact on the flow of control.
3. build a state diagram for the system
   • A passive state is simply the current status of all of an object’s attributes
   • The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.
   • An event (sometimes called a trigger ) must occur to force an object to make a transition from one active state to another.
   • Objects in the system change their state in response to events
   • UML state machine diagram documents these kinds of changes.
4. review the behavioral model to verify accuracy and consistency.

Action and activity

• entry/action: discrete action, perform only once at the entrance to the state
• do/activity: continuous activity throughout the state live span
• exit/action: discrete action, perform only once at the exit of the state

---

9. Design Concepts

9.1 Design in the SE context

Software Design emcompasses the set of

• principles
• concepts
• practices

The goal of design is to produce a model or representation that exhibits

• Firmness (no bugs)
• Commodity (useful or valuable)
• Delight (pleasuarble experience)

Software design is:

• The last software engineering action within the modelling activity and sets the stage for construction (code generation and testing)
• A process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation
• The requirements describe the function of a system as seen by the client.
• For a given set of requirements (analysis), the software development team must design a system that will meet those requirements.
• In practice requirements and design are interrelated. In particular, working on the design often clarifies the requirements.

• Component-level design: transforms structural elements of the software architecture into a procedural description of software components.
• Interface design: describes how the software communicates with systems that interoperate with it, and with humans who use it.
• Architectural design: defines the relationship between major structural elements of the software, the architectural styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented.
• Data design/class design: transforms class models into design class realizations and the requisite data structure required to implement it.

9.2 Quality control in the design process

• The importance of software design can be stated with a single word – quality
• Design provides you with representations of software that can be assessed for quality.
• Three goals a design in good quality
  • The design should implement all of the explicit requirements contained in the requirements model, and it must accommodate all of the implicit requirements desired by stakeholders.
  • The design should be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
  • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
• Eight technical criteria for evaluation:
  • A design should exhibit an architecture that
    • has been created using recognizable architectural styles or patterns
    • is composed of components that exhibit good design characteristics
    • can be implemented in an evolutionary fashion, thereby facilitating implementation and testing
  • A design should be modular; that is, the software should be logically partitioned into elements or subsystems.
  • A design should contain distinct representations of data, architecture, interfaces, and components.
  • A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns
  • A design should lead to components that exhibit independent functional characteristics.
  • A design should lead to interfaces that reduce the complexity of connections between components and with the.
  • A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
  • A design should be represented using a notation that effectively communicates its meaning.
• Five quality attributes (FURPS):
  • Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system.
  • Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
  • Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.
  • Performance is measured using processing speed, response time, resource consumption, throughput, and effi ciency.
  • Supportability combines extensibility, adaptability, and serviceability. These three attributes represent a more common term, maintainability— and in addition, testability, compatibility, configurability, the ease with which a system can be installed, and the ease with which problems can be localized.

9.3 The idea/principles behind software design

• provide the software designer with a foundation form which more sophisticated design methods can be applied
• defines criteria that can be used to partition software into individual component
• establish uniform criteria that define the technical quality of software design

Some general design concepts:

9.3.1 Abstraction

• Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
• The higher the level, the less the detail.
• At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment.
• At lower levels of abstraction, a more detailed description of the solution is provided
• As different levels of abstraction are developed, you work to create both procedural and data abstractions
• A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.
• A data abstraction is a named collection of data that describes a data object.

9.3.2 Modularity

• Modular design helps us to better organize complex system.
• It basically clusters similar or relative functions together, sets up boundaries and provides interfaces for communication
  • mobile phone as an complex system that is modularized
  • modularity increases manufacture efficiency and save time
• Modularity allows the possibility of the development of system parts to be carried out independently of each other, therefore reducing development time
• Software is divided into separately named and addressable components or modules that are integrated to satisfy requirements.
• In almost all instances, you should break the design into many modules to make understanding easier.
• However, too many modules in a system increase the complexity of modules integration
• Given the same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost) associated with integrating the modules also grows. These characteristics lead to a total cost or effort curve shown in the figure.
  
• For modularity, each module needs to support a well-defined
  abstraction and have a clear interface through which it can interact with other modules
• Coupling and cohesion are two modularization criteria, which are often used together

9.3.3 Functional Independence

• Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules.
• Software with effective modularity, that is, independent modules, is easier to develop, maintain and test
• Independence is assessed using two qualitative criteria: coupling and cohension.

9.3.4 Coupling

• Coupling refers to how focused a class or a module is
• Two modules are considered independent if one can function completely without the other
• If two modules are independent, they are solvable and modifiable separately.
• However, all the modules in a system must interact so that together they produce the desired behavior of the system.
• The more connections between modules, the more dependent they are
• Highly coupled “modules are joined by strong interconnections, while loosely coupled” modules have weak interconnections.
• Coupling increases with the complexity and obscurity of the interface between module
• To solve and modify a module separately, we would like the modules to be loosely couple
• To keep coupling low we would like to minimize the number of interfaces per module and the complexity of each interface.

9.3.5 Cohesion

• Another way to lower the coupling between modules is to strengthen the bond between elements of the same module by maximizing the relationship between elements of the same module
• Cohesion is the degree of how closely the elements of a module are related to each other
• Cohesion refers to how focused a class or a module is.
• Cohesion of a module gives the designer an idea about whether the different elements of a module belong together in the same module.
• Method cohesion
  • a method that implements a clearly defined function, and all statements in the method contribute to implementing this function.
  • it focuses on the methods you write inside the class. A method should clearly state the intention of why it is written
• Class cohesion
  • A high class cohesion is the class that implements a single concept or abstraction with all elements contributing toward supporting this concept
  • Highly cohesive classes are usually more easily understood and more stable
  • Whenever there are multiple concepts encapsulated within a class, the cohesion of the class is not as high as it could be, and a designer should try to change the design to have each class encapsulate a single concept

9.3.6 Object-oriented design

• An object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state
• Object-oriented design processes involve designing object classes and the relationships between these classes
• When the design is realized as an executing program, the objects are created dynamically from these class definitions
• To develop an object-oriented design from concept to detailed, here are several things that you need to do
  • Understand and define the context and the external interactions with the system.
  • Design the system architecture.
  • Identify the principal objects in the system
  • Develop design models
  • Specify interfaces

9.3.7 Design classes

• As the design model evolves, you will define a set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution.
• Five different types of design classes, each representing a different layer of the design architecture, can be developed
  • User interface classes define all abstractions that are necessary for human-computer interaction (HCI) and often implement the HCI in the context of a metaphor
  • Business domain classes identify the attributes and services (methods) that are required to implement some element of the business domain that was defi ned by one or more analysis classes
  • Process classes implement lower-level business bstrac_x0002_tions required to fully manage the business domain classes.
  • Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software.
  • System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.
• “Well-formed” design classes should:
  • Complete and sufficient. A design class should be the complete
    encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class. Suffi ciency ensures that the design class contains only those methods that are suffi cient to achieve the intent of the class, no more and no less.
  • Primitiveness. Methods associated with a design class should be focused on accomplishing one service for the class.
  • High cohesion. A cohesive design class has a small, focused set of
    responsibilities and single-mindedly applies attributes and methods to
    implement those responsibilities.
  • Low coupling. Within the design model, it is necessary for design classes to collaborate with one another.

9.4 Elements in design model

• Data design elements
• Architectural Design Element
• Interface Design Element
• Component-Level Design Element
• Deployment-Level Design Element

• Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data).
• It is then refined into progressively more implementation-specific representations that can be processed by the computer-based system
• Program-component level: essential to the creation of high- quality applications
• Application level: pivotal to achieving the business objectives of a system
• Business level: enables data mining or knowledge discovery that can have an impact on the success of the business itself
• The architectural design for software is the equivalent to the floor plan of a house. The floor plan depicts the overall layout of the rooms; their size, shape, and relationship to one another; and the doors and windows that allow movement into and out of the rooms. The floor plan gives us an overall view of the house. Architectural design elements give us an overall view of the software.
• Three sources:
  • information about the application domain for the software to be built;
  • specific requirements model elements such as use cases or analysis classes, their relationships and collaborations for the problem at hand;
  • the availability of architectural styles and patterns
• The interface design for software is analogous to a set of detailed drawings (and specifi cations) for the doors, windows, and external utilities of a house
• The interface design elements for software depict information flows into and out of a system and how it is communicated among the components defi ned as part of the architecture
• Three important elements:
  • the user interface (UI),
  • external interfaces to other systems, devices, networks, or other producers or consumers of information
  • internal interfaces between various design components

• Deployment-level design elements indicate how software
  functionality and sub-systems will be allocated within the physical computing environment that will support the softwar
  

---

10. Software Design

10.1 Architecture Design

• Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system.
• It is the first stage in the software design process, and the critical link between design and requirements engineering.
• It identifies the main structural components in a system and the relationships between them
• The output of this design process is a description of the software architecture.
• Design software architectures at two levels of abstraction:
  • Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. This chapter is mostly concerned with program architectures.
  • Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.
• Software architecture affects performance, robustness, distributability, and maintainability
• Individual component: implement functional requirements
• System architecture: fulfill non-functional requirement
• Non-functional requirement also influenced by individual component, but mostly by system architecture.

Advantages

• Stakeholder communication: Architecture may be used as a focus of discussion by system stakeholders.
• System analysis: Means that analysis of whether the system can meet its non- functional requirements is possible
• Large-scale reuse: The architecture may be reusable across a range of systems. Product-line architectures may be developed.

representations

• Simple, informal block diagrams showing entities and relationships are the most frequently used method for documenting software architectures
• But these have been criticized because they lack semantics, do not show the types of relationships between entities nor the visible properties of entities in the architecture

Architectural Design Decisions

• Architectural design is a creative process so the process differs depending on the type of system being developed.
• However, a number of common decisions span all design processes and these decisions affect the non- functional characteristics of the system.
  

Architectural views

• A logical view, which shows the key abstractions in the system as objects or object classes.
• A process view, which shows how, at run-time, the system is composed of interacting processes.
• A development view, which shows how the software is decomposed for development.
• A physical view, which shows the system hardware and how software components are distributed across the processors in the system.
• Related using use cases or scenarios (+1)

10.1.1 Architectural patterns

• Patterns are means of representing, sharing and reusing knowledge.
• An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.
• Patterns should include information about when they are and when the are not useful.
• Patterns may be represented using tabular and graphical descriptions.

MVC Pattern
Model-View-Controller(MVC pattern)

This pattern is the basis of interaction management in many web-based systems.
It includes three major interconnected components:

• Model: central component of the pattern that directly manages the data, logic and rules of the application.
• View：can be any output representation of information, such as a chart or a diagram.
• Controller: accepts input and converts it to commands for the model or view, enables the interconnection between the views and the model.

Layered Pattern

Layered Pattern: the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.
This layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users.
Performs poorly in the high-performance applications, because it is not efficient to go through multiple layers to fulfil a business request. It is a good choice for situations with a very tight budget and time constraints

Repository Patterns

Client-server Patterns

Pipe and Filter Patterns

10.2 Component-level Design

• Component-level design occurs after the first iteration of architectural design has been completed.
• A complete set of software components is defined during architectural design.
• But the internal data structures and processing details of each component are not represented at a level of abstraction that is close to code.
• Component-level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component.
• A component-level design can be represented using some intermediate representations (e.g. graphical, tabular, or text-based) that can be translated into source code.

10.2.1 Component

• A software component is a modular building block for computer software.
• It can be used to review for correctness and consistency with other components.
• It can be used to access whether data structure, interfaces and algorithms will work.
• It should provide sufficient information to guide implementation.

10.2.2 Views of component

Object-oriented view

• From an object-oriented viewpoint, a component is a set of collaborating classe.
• Each class within a component is fully elaborated to include all attributes and operations that are relevant to its implementation.
• All interfaces that enable the classes to communicate and collaborate with other design classes are also defined.

Traditional view

• Traditionally, a component is a functional element of a program that incorporates
  • processing logic
  • the internal data structures that are required to implement the processing logic.
  • an interface that enables the component to be invoked and data to be passed to it.

Process-related view

• Emphasis is placed on building system from existing components maintained in a library rather than creating each component from scratch.
• As the software architecture is developed, you choose components or design patterns from the catalog and use them to populate the architecture.

10.2.3 Component-level design process

10.3 User Interface Design

CPT203-Software Engineering相关推荐

1. Software Engineering 265

   代做Engineering 265作业.代写Python编程作业.代做Python作业.代做via Gitlab作业 Software Engineering 265 Software Develop ...

2. Software Engineering at Google

   Google的Fergus Henderson在Software Engineering at Google中介绍了Google的软件工程实践. 软件开发 源码仓库 单一源代码仓库,除了核心配置和安全 ...

3. 加州大学欧文计算机工程硕士,UCI加州大学尔湾分校软件工程硕士Master of Software Engineering...

   软件工程硕士Master of Software Engineering是加州大学尔湾分校研究生申请的热门专业,下面由美英港新教育重点介绍软件工程硕士研究生的课程设置.培养目标.申请要求及学费. 培养 ...

4. SoftWare Engineering -- WEEK.3

   SoftWare Engineering – WEEK.3 2022.3.18 @Raoquan WEEK.3 List 0. Coursework some details 1. Requireme ...

5. Software Engineering at Google翻译-III-11-Testing overview（测试概述）

   参考: https://github.com/daizhenhong/swe-at-google/blob/main/Part_III_Processes/total/Chapter-11-total ...

6. 软件工程（Software Engineering）

   软件工程(Software Engineering) GTI-分布式版本控制系统 查看已有的git配置信息 DVOS运维一体化 单分支模型 exit git --version git clone u ...

7. Something about Software Engineering

   文章目录 软件工程 定义 Definition 软件危机 Software Crisis 软件生命周期 软件工程知识体系 SWEBoK(Software Engineering Body of Kno ...

8. 【北邮国院大三下】Software Engineering 软件工程 Week1

   北邮国院大三电商在读,随课程进行整理知识点.仅整理PPT中相对重要的知识点,内容驳杂并不做期末突击复习用.个人认为相对不重要的细小的知识点不列在其中.如有错误请指出.转载请注明出处,祝您学习愉快. 编 ...

9. 论文阅读：Empirical software engineering experts on the use of students and professionals in experiments

   题目:Empirical software engineering experts on the use of students and professionals in experiments ES ...

10. 个人阅读作业2—《No Silver Bullet: Essence and Accidents of Software Engineering》读后感

    在进行了一次结对编程.一次团队编程和一次个人编程项目后,读了<No Silver Bullet: Essence and Accidents of Software Engineering> ...

最新文章

1. 积累有价值的seo资源提高网站优化效果
2. java示例_Java入门示例
3. 动态ram依靠什么存储信息_ROM、RAM、DRAM、SRAM和FLASH傻傻分不清
4. [Err] 22007 - [SQL Server]从 nvarchar 数据类型到 datetime 数据类型的转换产生一个超出范围的值。
5. python之路_自定义属性、json及其他js补充
6. 网页统计所用到的名词解析
7. 小鹏汽车上市首日股价大涨41.47% 市值150亿美元
8. [转载] Python format()格式：中文对齐问题
9. WCDMA中的TSTD和STTD
10. [转]网络安全设备Bypass功能介绍及分析 - [网络编程]
11. Python初学系列——天天向上的力量
12. UEditor自定义工具栏图标
13. 电工——人社三方——职业技能等级证书
14. Python3.5 ‘wb’与‘w’区别以及写入excel的常见错误
15. 苹果个人账户转成公司账户
16. 中国矿业大学计算机学院地址,中国矿业大学校区有几个 地址是什么
17. IOS 跨域问题分析和处理
18. scrapy保存图片、音频
19. python爬虫项目毕业设计_基于python爬虫的电影推荐网站的设计与实现毕业论文+初稿+项目源码+安装说明+使用说明...
20. JavaSwing+MySQL+进销存管理系统

热门文章

1. 故障树FTA（fault tree analysis）工具链
2. HashSet模拟新浪微博用户注册
3. MATLAB安装后出现问题：MTALAB2021安装后闪退打不开
4. 大连发展中韩跨境电子商务势在必行
5. MAC读取NTFS移动硬盘方法
6. 使用mysql打开什么文件格式_dbf是什么文件怎么打开
7. 【java学习】面向对象编程(一)【详解篇13】
8. html中图片集合,HTML标签大集合
9. 关于java的国内外论坛地址分享
10. 国外的英文JAVA论坛