SE test 1

A Process Framework

Framework activities Umbrella Activities

Hardware and Software failure costs

Hardware failures ▪ Design/manufacturing defects ▪ Steady after correction ▪ Wear off due to dust, vibration, use Software failures ▪ Undiscovered defects ▪ Spiking error rate due to changes ▪ Software deteriorates

Tabular specification - Class-responsibility-collaborator (CRC) modeling

A CRC model is a collection of standard index cards that represent classes. Each card is divided into 3 sections: • Class: Name of the class. • Responsibility: the attributes and operations that are relevant for the class. A responsibility is "anything the class knows or does". • Collaborator: are those classes that are required to provide the class with the information needed to complete a responsibility. A collaboration implies either a request for information or a request for some action.

Stakeholders in the Mentcare system (2/2)

A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care. Health care managers who obtain management information from the system. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented.

Ethnography

A social scientist spends a considerable time observing and analyzing how people actually work. People do not have to explain or articulate their work. Social and organizational factors of importance may be observed. Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system.

Scenarios

A structured form of user story Scenarios should include ▪ A description of the starting situation; ▪ A description of the normal flow of events; ▪ A description of what can go wrong; ▪ Information about other concurrent activities; ▪ A description of the state when the scenario finishes.

Extreme programming (XP)

A very influential agile method, developed in the late 1990s, that introduced a range of agile development techniques. XP takes an 'extreme' approach to iterative development. ▪ New versions may be built several times per day; ▪ Increments are delivered to customers every 2 weeks; ▪ All tests must be run for every build and the build is only accepted if tests run successfully.

Other Agile Models

Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP)

Structured specifications

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements.

System stakeholders

Any person or organization who is affected by the system in some way and so who has a legitimate interest Stakeholder types ▪ End users ▪ System managers ▪ System owners ▪ External stakeholders

Problems with interviews

Application specialists may use language to describe their work that isn't easy for the requirements engineer to understand. Interviews are not good for understanding domain requirements ▪ Requirements engineers cannot understand specific domain terminology; ▪ Some domain knowledge is so familiar that people find it hard to articulate or think that it isn't worth articulating.

3. Requirements validation

Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important ▪ Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Functional requirements

Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail.

Agile methods

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: ▪ Focus on the code rather than the design ▪ Are based on an iterative approach to software development ▪ Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

Interviewing

Formal or informal interviews with stakeholders are part of most RE processes. Types of interview ▪ Closed interviews based on pre-determined list of questions ▪ Open interviews where various issues are explored with stakeholders. Effective interviewing ▪ Be open-minded, avoid pre-conceived ideas about the requirements and be willing to listen to stakeholders. ▪ Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Types of requirements

Functional requirements ▪ Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. ▪ May state what the system should not do. Non-functional requirements ▪ Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. ▪ Often apply to the system as a whole rather than individual features or services.

Goals vs. requirements

Goal ▪ A general intention of the user such as ease of use. ▪ Example: The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) Verifiable non-functional requirement ▪ A statement using some measure that can be objectively tested. ▪ Example: Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)

Requirements completeness and consistency

In principle, requirements should be both complete and consistent. Complete ▪ They should include descriptions of all facilities required. Consistent ▪ There should be no conflicts or contradictions in the descriptions of the requirements.

Uploading photos (iLearn)

Initial assumption: A user or a group of users have one or more digital photographs to be uploaded to the picture sharing site. These are saved on either a tablet or laptop computer. They have successfully logged on to KidsTakePics. Normal: The user chooses upload photos and they are prompted to select the photos to be uploaded on their computer and to select the project name under which the photos will be stored. They should also be given the option of inputting keywords that should be associated with each uploaded photo. Uploaded photos are named by creating a conjunction of the user name with the filename of the photo on the local computer. On completion of the upload, the system automatically sends an email to the project moderator asking them to check new content and generates an on-screen message to the user that this has been done.

Representing requirements in natural language

Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon. Include an explanation (rationale) of why a requirement is necessary.

Problems with natural language

Lack of clarity ▪ Precision is difficult without making the document difficult to read. Requirements confusion ▪ Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation ▪ Several different requirements may be expressed together.

Uploading photos (iLearn) what could go wrong

No moderator is associated with the selected project. An email is automatically generated to the school administrator asking them to nominate a project moderator. Users should be informed that there could be a delay in making their photos visible. Photos with the same name have already been uploaded by the same user. The user should be asked if they wish to re-upload the photos with the same name, rename the photos or cancel the upload. If they chose to re-upload the photos, the originals are overwritten. If they chose to rename the photos, a new name is automatically generated by adding a number to the existing file name. Other activities: The moderator may be logged on to the system and may approve photos as they are uploaded. System state on completion: User is logged on. The selected photos have been uploaded and assigned a status 'awaiting moderation'. Photos are visible to the moderator and to the user who uploaded them.

Stakeholders in the Mentcare system (1/2)

Patients whose information is recorded in the system. Doctors who are responsible for assessing and treating patients. Nurses who coordinate the consultations with doctors and administer some treatments. Medical receptionists who manage patients' appointments. IT staff who are responsible for installing and maintaining the system.

Plan-driven and agile development

Plan-driven development ▪ Based around separate development stages with the outputs to be produced at each of these stages planned in advance. ▪ Not necessarily waterfall model - plandriven, incremental development is possible ▪ Iteration occurs within activities. Agile development ▪ Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

Requirements imprecision

Problems arise when functional requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term 'search' in requirement 1 of Mentcare system. ▪ User intention - search for a patient name across all appointments in all clinics; ▪ Developer interpretation - search for a patient name in an individual clinic. User chooses the clinic, then searches

Non-functional classifications

Product requirements ▪ Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organizational requirements ▪ Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements ▪ Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

1&2. Requirements elicitation and analysis process

Requirements elicitation is also called requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system's operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Requirements discovery ▪ Interacting with stakeholders to discover their requirements. Requirements classification and organization ▪ Groups related requirements and organizes them into coherent clusters. Prioritization and negotiation ▪ Prioritizing requirements and resolving requirements conflicts. Requirements specification ▪ The process of writing down the requirements in a requirements document. Then, these specifications are input into the next round of the spiral.

Stories and scenarios

Scenarios and user stories are real-life examples of how a system can be used. Stories and scenarios are a description of how a system may be used for a particular task. Because they are based on a practical situation, stakeholders can relate to them and can comment on their situation with respect to the story.

Scrum

Scrum principles are used to guide the following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks occur within a process pattern called a sprint. ▪ The number of sprints required for each framework activity will vary depending on product complexity and size. Backlog—a prioritized list of project requirements or features that provide business value for the customer. Sprints—consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box (typically 30 days). ▪ A time-box is a project management term that indicates a period of time that has been allocated to accomplish some task. Scrum meetings—are short meetings (typically 15 minutes) held daily by the Scrum team. Lead by the team leader called scrum master. ▪ What did you do since the last team meeting? ▪ What obstacles are you encountering? ▪ What do you plan to accomplish by the next team meeting?

Problems of requirements elicitation

Stakeholders don't know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organizational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.

Requirements engineering

The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed.

Requirements discovery

The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. Interaction is with system stakeholders from managers to external regulators.

Requirements engineering (RE) processes

The processes used in RE vary widely depending on the application domain, the people involved and the organization developing the requirements. However, there are a number of generic activities common to all processes 1. Requirements elicitation 2. Requirements analysis 3. Requirements validation 4. Requirements management In practice, RE is an iterative activity in which these processes are interleaved.

Non-functional requirements

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

Use cases

Use-cases are a kind of scenario that are included in the UML. Use cases identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. High-level graphical model supplemented by more detailed tabular description (see Chapter 5). UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

Tabular specification

Used to supplement natural language. Particularly useful when you have to define a number of possible alternative courses of action. For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.

Metrics for specifying non-functional requirements

- Speed - Size - Ease of use - Reliability - Robustness - Portability

Principles of Agile Methods

-Customer involvement --Customers should be closely involved throughout the development process. Their role is to 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 each 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.

Mentcare system: Functional requirements

1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. 3. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

Essential attributes of good software

1. Maintainability 2. Dependability and Security 3. Efficiency 4. Acceptability

iLearn: A digital learning environment

A digital learning environment is a framework in which a set of general-purpose and specially designed tools for learning may be embedded plus a set of applications that are geared to the needs of the learners using the system. The tools included in each version of the environment are chosen by teachers and learners to suit their specific needs. ▪ These can be general applications such as spreadsheets, learning management applications such as a Virtual Learning Environment (VLE) to manage homework submission and assessment, games and simulations.

A Generic Process Model

A generic process framework for software engineering defines five framework activities— communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk management, quality assurance, configuration management, technical reviews, etc.— are applied throughout the process.

Mentcare: A patient information system for mental health care

A patient information system to support mental health care is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received. Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems. To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centers.

Case studies

A personal insulin pump ▪ An embedded system in an insulin pump used by diabetics to maintain blood glucose control. A mental health case patient management system ▪ Mentcare. A system used to maintain records of people receiving care for mental health problems. A wilderness weather station ▪ A data collection system that collects data about weather conditions in remote areas. iLearn: a digital learning environment ▪ A system to support learning in schools

The waterfall model (classic lifecycle)

A standard software process model Testing or validation after each step ▪ move to a phase only when its preceding phase is reviewed and verified No iterations (some variants allow feedback between steps)

The V-model

A variation in the representation of the waterfall model. Depicts the relationship of quality assurance actions with communication, modeling, and early construction activities. As software team moves down the left side of V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution. Once code is generated, the team moves up the right side of V, performing tests (quality assurance) to validate each of the models created as the team moved down the left side. The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work.

Incremental process model - example

A word-processing software developed using incremental process model may generate the following: ▪ first increment - might deliver basic file management, editing, and document production functions ▪ second increment - more sophisticated editing and document production capabilities ▪ third increment - spelling and grammar checking ▪ fourth increment - advanced page layout capability Note that the process flow for any increment can incorporate the prototyping paradigm.

Advantages of prototyping

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately.

Insulin pump control system

Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected. Calculation based on the rate of change of blood sugar levels. Sends signals to a micro-pump to deliver the correct dose of insulin. Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood sugar levels have long-term consequences such as eye and kidney damage.

Incremental process model

Combines elements of linear and parallel process flows. It applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable "increments" of the software.

Framework Activities

Communication Planning Modeling ▪ Analysis of requirements ▪ Design Construction ▪ Code generation ▪ Testing Deployment

Issues of professional responsibility

Confidentiality ▪ Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence ▪ Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence. Intellectual property rights ▪ Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse ▪ Software engineers should not use their technical skills to misuse other people's computers. Computer misuse ranges from relatively trivial (game playing on an employer's machine, say) to extremely serious (dissemination of viruses).

Mariner (1962) software disaster

Cost: $18.5 million Disaster: First spacecraft of NASA's Mariner program headed for Venus diverted from its route immediately after its launch. It was destroyed 293 sec. after launch. Software Problem: A missing overbar (aka missing hyphen) ▪ A smoothing function indicated by the bar was not executed ▪ Program took normal variations in velocity as serious, attempted faulty corrections each time and sent the rocket off route.

Wall Street Disaster (1987)

Cost: $500 billion Disaster: The Dow Jones Industrial Average plummeted 508 points (22.6% loss). The S&P 500 dropped 20.4% (Black Monday) Software Problem: Securities and Exchange Commission (SEC) investigations initiated investors to issue mass amounts of sell orders, which eventually crashed the system.

Hartford Coliseum Collapse (1978)

Cost: $90 million Disaster: Steel roof collapsed under heavy snow. Software Problem: CAD software assumed the steel roof would only endure compression, not snow

Medical Disaster (1985)

Cost: 3 fatalities, 3 injured Disaster: A malfunctioned radiation therapy machine in Canada delivered lethal doses of radiation to patients. Software Problem : Due to race condition bug, a technician could accidentally configure the machine so that it issued high levels of radiation without patient protection.

7. AT&T Lines Collapse (1990)

Cost: 75 million calls missed, 200.000 airline reservations lost Disaster: One switch among 114 switching centers suffered a minor mechanical problem and shut down the center. When it resumed, it sent a message to all other switching centers and caused them to shut down for 9 hours. Software Problem : A ripple effect caused by software to speed up calling.

World War III? (1983)

Cost: ??? Disaster: A false alarm in the Soviet early warning system about US launching 5 ballistic missiles. ▪ Soviets thought 5 is too few!! Software Problem: A bug in the Soviet software failed to filter out false missile detections caused by sunlight reflecting off cloud-tops.

CIA Soviet Union Crisis (1982)

Cost: Millions of dollars, significant damage to Soviet economy Disaster: Software control failed causing too high pressure on the Trans-Siberian gas pipeline and it exploded. Software Problem: (It's complicated) CIA operatives allegedly planted a bug in a Canadian computer system purchased by the Soviets to control their gas pipelines. Soviets allegedly wanted to access sensitive U.S. technology. CIA discovered the purchase, they sabotaged it so that would pass Soviet inspection but fail in operation.

Advantages of waterfall model

Defines all the basic activities for a software process Emphasis on documents and specifications to support high-quality software Simple and straightforward to implement

Ethical dilemmas

Disagreement in principle with the policies of senior management. Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. Participation in the development of military weapons systems or nuclear systems.

The waterfall model - NASA example

Each execution handles $4Billion equipments, human lives, dreams ▪ 420k lines of code, 17 errors in 11 versions ▪ Commercial equivalent would have 5000 bugs 1/3rd of effort spent before coding Long specifications, written down, fully discussed ▪ 40k pages of specification (longer than the code) ▪ Change to add GPS support (2500 pages more specification) ▪ Specification is almost pseudo code Validation and review at all levels ▪ 85% of bugs revealed before testing Cost ▪ 260 people ▪ $32 million ▪ one year TOO EXPENSIVE!!! Overkill for normal software

Evolutionary models

Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software. The two common evolutionary process models are: ▪ Prototyping ▪ Spiral model

General issues that affect 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. Scale ▪ Software has to be developed across a very wide range of scales, from very small embedded systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community.

Reasons for software project failure

Increasing system complexity reason: ▪ As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; systems have to have new capabilities that were previously thought to be impossible. Failure to use software engineering methods reason: ▪ Some companies have drifted into software development as their products and services have evolved. But they do not use software engineering methods. Consequently, their software is often more expensive and less reliable than it should be.

Key features of the Mentcare system

Individual care management ▪ Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors can quickly learn about the key problems and treatments that have been prescribed. Patient monitoring ▪ The system monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected. Administrative reporting ▪ The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, number of patients sectioned, the drugs prescribed and their costs, etc.

Evolutionary models - The spiral model

Is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. Software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

Disadvantages of the spiral model

It may be difficult to convince customers that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur

Mentcare

Mentcare is an information system that is intended for use in clinics. It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.

Mentcare system concerns

Privacy ▪ It is essential that patient information is confidential and is never disclosed to anyone apart from authorised medical staff and the patient themselves. Safety ▪ Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients. ▪ The system must be available when needed otherwise safety may be compromised and it may be impossible to prescribe the correct medication to patients.

Different ways of representing requirements

Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural language The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don't understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

The ACM/IEEE Code of Ethics - Ethical Principals

PUBLIC CLIENT AND EMPLOYER PRODUCT JUDGMENT MANAGEMENT PROFESSION COLLEAGUES SELF

Examples of non-functional requirements in the Mentcare system

Product requirement The Mentcare system shall be available to all clinics during normal working hours (Mon-Fri, 0830-17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the Mentcare system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

Disadvantages of waterfall model

Relies on precise and stable requirements Users cannot involve much (specifications are difficult to understand) Takes too long to finish Small errors (or requirement changes) at the beginning steps are unaffordable Suitable for projects with specific critical software, no competition, enough resources

Software costs

Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development.

Software engineering ethics

Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law but involves following a set of principles that are morally correct.

Umbrella Activities

Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management

Software process activities

Software specification, software development, software validation and software evolution.

Evolutionary models - The spiral model continued

Spiral model is divided into a set of framework activities. Each of the framework activities represent one segment of the spiral path. As evolutionary process begins, software team performs activities implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk is considered as each revolution is made. Anchor point milestones—a combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software.

Disadvantages of prototyping

Stakeholders allured by a working version of the software, even though imperfect with lacking quality and long-term maintainability. They only demand that "a few fixes" to the prototype and software development management relents. Software engineers make compromises to get a working prototype. An inappropriate OS, or programming language, an inefficient algorithm may be used. After a time, you may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system.

Evolutionary models - Prototyping continued

Suitable when a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features. Or, when the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. Can be used as a stand-alone process model, or within the context of any one of the process models

Software engineering

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; i.e. the application of engineering to software. —IEEE— The systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software —The Bureau of Labor Statistics— The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines"—Fritz Bauer.

Wilderness weather station

The government of a country with large areas of wilderness decides to deploy several hundred weather stations in remote areas. Weather stations collect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed and wind direction. ▪ The weather station includes a number of instruments that measure weather parameters such as the wind speed and direction, the ground and air temperatures, the barometric pressure and the rainfall over a 24-hour period. Each of these instruments is controlled by a software system that takes parameter readings periodically and manages the data collected from the instruments.

Refactoring

The process of changing a software system such that it does not alter the external behavior of the code yet improves the internal structure. It is a disciplined way to clean up, modify/simplify the internal design to minimize bugs.

ACM/IEEE Code of Ethics

The professional societies in the US have cooperated to produce a code of ethical practice. Members of these organizations sign up to the code of practice when they join. The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.

Evolutionary models - Prototyping

The prototyping paradigm begins with communication: Meeting with stakeholders to define the overall objectives, and to identify requirements. A prototyping iteration is planned quickly, and modeling (in the form of a "quick design") occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders.

Advantages of the spiral model

The spiral model is a realistic approach to the development of largescale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism and enables the application of prototyping approach at any stage during evolution. It maintains the systematic stepwise approach suggested by the classic life cycle, while incorporating an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic.

Essential high-level requirements

The system shall be available to deliver insulin when required. The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar. The system must therefore be designed and implemented to ensure that the system always meets these requirements.

Weather information system

The weather station system ▪ This is responsible for collecting weather data, carrying out some initial data processing and transmitting it to the data management system. The data management and archiving system ▪ This system collects the data from all of the wilderness weather stations, carries out data processing and analysis and archives the data. The station maintenance system ▪ This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems.

Mentcare goals

To generate management information that allows health service managers to assess performance against local and government targets. To provide medical staff with timely information to support the treatment of patients.

iLearn services

Utility services that provide basic applicationindependent functionality and which may be used by other services in the system. Application services that provide specific applications such as email, conferencing, photo sharing etc. and access to specific educational content such as scientific films or historical resources. Configuration services that are used to adapt the environment with a specific set of application services and do define how services are shared between students, teachers and their parents.

The software process

When you work to build a product or system, it is important to go through a series of predictable steps—a road map that helps you create a timely, high-quality result. The road map that you follow to generate software is called a "software process."

CRC

class-responsibility-collaborator

Process flow

process flow describes how the framework activities and the actions and tasks that occur within each framework activity are organized w.r.t. sequence and time.