What kind of people are involved in development process?

People play an important role in the development process. One should understand the people involved in the software development process, particularly, their interest regarding the system and the software that needs to be developed.

End-users are the people who will be using the end-product. Some end users are directly involved and some are indirectly involved. Those who are directly involved are:

- Operational Job: They perform the operational functions of the system. They are concerned with the human interface component of the system like what keyboard, display screen you are using? They have the local view of the system. They tend to think of the system in physical terms.

- Supervisor Job: They perform supervisory actions on daily operations of the system. They are most likely to be concerned with the operational efficiency of the functions that needs to be performed such as more output in less time. They also tend to have same local and physical view of the system similar with the operational users. they are the users who have more contact with the software engineers.

- Executive Job: They generally provide the initiative and serve as the funding authority of the system development project. They are less likely to be concerned with the day to day activities. They are more concerned with strategic issues and long term profit and loss. They are more interested in global view of the system. They are generally able to work with abstract models of the system rather than the physical terms.

What is a System? What are general principles of system?

System is an:
- integrated set of inter-operable elements;
- it consists of group of entities or components;
- interacting together to form specific inter-relationships;
- organized by means of structure;
- working together to achieve a common goal.

In defining the system boundaries,a software engineer discovers the following:
- entities or group of entities that are related and organized in some way within the system, either they provide input, do activities or receive output;
- activities or actions that must be performed by the entities or group of entities in order to achieve the purpose of the system;
- a list of inputs;
- a list of outputs.
Entities that are involved in this system are the applicant, club staff and coach.

General Principles of Systems
- The more specialized a system, the less it is able to adapt to different circumstances.
- The larger the system is, the more resources must be devoted to its everyday maintenance
- Systems are always part of larger systems, and they can always bepartitioned into smaller systems

There are two types of systems, namely, man-made systems and automated systems. Man made systems will always have areas for correctness and improvements. These areas for correctness and improvements can be addressed by automated systems. Automated systems consists of computer hardware, computer software, people, procedures, data and information and the connectivity that allows the connection of one computer systemwith another computer system.

What is a software process? What are different types of software process models?

A strategy that a software development team employs in order to build quality software is called software process. A software process is chosen based on:
- nature of the project and application.
- methods and tools to be used.
- management and work products that are required.

A software process consists of:
- Framework activities: People who are involved in the development process perform these activities. They are alsoknown as phases of the software development process.
- Tasks sets: The activities in the process framework defines a set of tasks. These tasks would have milestones, deliverables or work products and software quality assurance (SQA) points.
- Umbrella activities: These are the activities that supports the framework of activities as the software development project progresses such as software project management, change management, requirements management, risk management, formal technical reviews.

Types of Software Process Models
- Linear Sequential Model
- Prototyping Model
- Rapid Application Development (RAD) Model
- Evolutionary Process Models which includes Incremental Model, Spiral Model and
Component-based Assembly Model.
- Concurrent Development Model
- Formal Methods

Factors that Affect the Choice of Process Model
- Type of the Project
- Methods and Tools to be Used
- Requirements of the Stakeholders
- Common Sense and Judgment

Formal Technical Review - Fagan's Inspection Method

Fagan's Inspection Method is introduced by Fagon. Apart from checking codes of programs,it is used to check other work products such as technical documents, model elements, data and code design etc. It follows certain procedural rules that each member should follow:
- The time limit for an inspection meeting is for two hours.
- Inspections are led by a trained moderator.
- Inspections are carried out at a number of points in the process of project planning and systems development.
- All classes of defects in documentation and work product are inspected.
- Inspection is carried out by colleagues at all levels of seniority except the big boss.
- Inspectors are assigned specific roles to increase effectiveness.
- Statistics on types of errors are key, and used for reports which are analyzed in a manner similar to financial analysis.

Different activities that are involved in conducting inspections are:
- Planning is very important and in this case the moderator is asked to build up a plan.
- Presentation should be given which gives an overall overview.
- Each inspector is given 1 to 2 hours alone to inspect the workproduct.
- Meeting should be held in which participants of the meeting are the inspectors, moderator and the developer of the work product.
- The defect list is given for repair.
- Follow up with the repair work.
- Casual analysis meeting is held where inspectors are given a chance to express their personal view on errors and improvements.

What are Formal Technical Reviews (FTR)? What is the aim and guidelines for formal technical reviews?

When tasks are performed in software process, the result is a work product. These results contribute to the development of quality software.
A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives:
- uncover errors in function, logic or implementation of the software.
- verify that the software meets its requirements.
- ensure that the software has been developed according to the standards.
- achieve uniform software.
- make projects manageable.

Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.
The purpose of formal technical review serves as a training ground for junior engineers and to promote backup and continuity.
Constraints of formal technical review meeting’s include 3-5 people involvement, advanced preparation not more than 2 hours for each person, the duration of the review meeting should be less than 2 hours and focus on a specific part of a software product.

There are few guidelines while conducting formal technical reviews. They are:
- Work product should be reviewed and not the developer.
- Make a practice to write down notes while conducting reviews.
- Agenda should be planned.
- Minimize the debate and discussions.
- Keep the number of participants to a minimum and insist on preparing for the review.
- The defect areas should be pointed but no solution should be provided.
- A checklist that is to be reviewed is provided.
- Schedule the reviews as part of the software process and ensure that resources are provided for each reviewer
- Check the effectiveness of review.

What are different activities that comprise Software Quality Assurance?

To build a quality software, software quality assurance comprise of different activities. People involved are development team and software quality assurance team. The team of software quality assurance is responsible for quality assurance planning, overseeing, analyzing, record keeping, defects analysis and rework.

The activities encompassing software quality assurance are:
- Software Quality Assurance Plan is prepared by SQA team. They identify the evaluation to be performed, audits and reviews to be performed, standards that are applicable, procedures for error reporting and tracking, documents to be produced and amount of feedback required.
- SQA team checks if the selected software development process conform to the organizational policy and quality standards.
- SQA team monitor and track deviations from the software development process. It reviews software engineering activities.
- SQA team reviews, monitor and track defects found with each work products. Documentations are done to ensure that corrections have been made.
- The SQA team ensures that deviations in the software activities and work products are handled based on defined standard operating procedures.
- The SQA team reports deviations and non-compliance to standards to the senior management or stakeholders.

Software quality assurance plans saves time, money, increases productivity, enhances training, provides extra support.

What is Software Quality Assurance (SQA)? What are characteristics of a well-engineered software?

Software Quality Assurance(SQA) is a function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
- It is a subset of software engineering that ensures that all deliverables and work products are meet, and they comply with user requirements and standards.
- Its goal is to detect defects before the software isdelivered as a final product to the end-users.
- It includes quality management approach.
- It includes effective methods and tools.
- It includes formal technical reviews.
- It includes a multi-tiered testing strategy.
- It includes control of software documentation.
- It includes a procedure to assure compliance with software development standards, and measuring and reporting mechanism.

How do we say that the software is well-engineered?

- A software should be easy to use by the user.
- A software should have the capability to be able to execute on different platforms.
- A software should be able to transfer from one system to another.
- A software should be able to evolve and adapt to changes over time.
- A software should be reliable, secure and safe.
- A software should be capable of using resources efficiently.

A software has quality if it is fit for use, i.e., it is working properly. It should conform to explicitly stated user's external characteristics, explicitly documented quality standards and implicit characteristics.

What is Quality and what are different perspectives used in understanding quality?

Quality is the total characteristic of an entity to satisfy stated and implied needs. Three perspectives are used in understanding quality:
- quality of the product
- quality of the process
- quality in the context of the business environment.

Quality of the Product
- The quality of the product has a different perspective for different people.
- End users assume that the software has quality if it gives what they want, when they want it, all the time. The ease of use and is also a important criterion for end users.
- For software engineers, they take a look at the internal characteristics rather than the external.

Quality of the Process
As software engineers, we valuethe quality of the software development process. Process guidelines suggests that byimproving the software development process,we also improve the quality of theresulting product. Common guidelines of process include Capability Maturity Model Integration (CMMI),ISO 9000:2000, Software Process Improvement and Capability Determination (SPICE).

Quality in the Context of Business Process
Quality is viewed in terms of the products and services being provided by the business in which the software is used. Improving the technical quality of the business process adds value to the business, i.e., technical value of thesoftware translates to business value.

To address quality issues:
- use quality standards.
- understand people involved in development process.
- understand the systematic biases in human nature.
- commit to quality.
- manage user requirements.

Software Engineering - Quality Focus, Process, Method and Tools

A computer software includes a set of programs that executes within a computer of any size and architecture, and data that are being processed by theprograms and presented to users as hard or soft copies.
- Software Engineering is a discipline that applies principles of engineering to the development of quality software in a timely and cost-effective manner.
- Software Engineering is viewed differently by different practitioners. It makes use of measurement and metrics to assess quality, not only of the software but also the software process.
- In layered technology, the foundation is total focus on quality.
- The process integrates the other layers together. It defines a framework that consists of key process areas that define and enable rational and timely delivery of the computer software.
- Methods define a systematic and orderly procedures of building software. Methodology is the science of systematic thinking using the methods orprocedures used in a particular discipline.
Structured methodology includes Information Engineering, Software Development Life Cycle/Project Life Cycle, Rapid Application Development Methodology, Joint Application Development Methodology, CASE Method.
Object-oriented Methodologies include Booch Method, Coad and Yourdan Method, Jacobson Method, Rumbaugh Method and Wirfs-Brock Method.
- Tools provide support to the process and methods. They may be automated or semi-automated. Most tools are used to develop models. Models are patterns of something to made or they are simplification of things. There are two models that are generally developed by system model is an inexpensive representation of a complex system that one needs to study while a software model is a blueprint of the software that needs to be built.
Structured Approach Modeling Tools include Entity-relationship Diagrams, Data Flow Diagrams, Structured English or Pseudo-codes, Flow Charts.
Object-oriented Approach Modeling Tools include Unified Modeling Language (UML).

Overview of Aspect Oriented Software Development (AOSD)

Aspect oriented software development defines aspects that express customer concerns that cut across multiple system functions, features, and information. It provides a process and methodological approach for defining, specifying, designing, and constructing aspects - mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concern.
Aspect Oriented Programming (AOP) provides the ability to intercept code execution with the purpose of inserting a process before, in place of, or after the code that would normally execute.

Predominant reasons for AOSD are:
- Help solve the issue of messy object architectures.
- Object oriented programming has difficulty dealing with global information.
- Also, functionality that requires the involvement of several different objects (possibly collected into a component) results in interdependency between those objects/components. This makes the application susceptible to the implementation changes of a dependent object/component.
- Maintenance and enhancement are also problems, as the interaction between these objects/components are typically hard coded within the containing object.

AOSD programming technologies (aspect-oriented programming, or AOP) provide linguistic mechanisms for separate expression of concerns, along with implementation technologies for weaving these separate concerns into working systems. Aspect-oriented software engineering (AOSE) technologies are emerging for managing the process of developing systems within this new paradigm.

Overview of The Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states.
It makes use of state charts to represents the concurrentrelationship among tasks associated within a framework of activities. It isrepresented schematically by a series of major technical tasks, and associated states. The user's need, management decisions and review results drive theover-all progression of the development.

The concurrent model is often more appropriate for system engineering projects where different engineering teams are involved. The concurrent process model defines a series of events that will trigger transitions from state to state for each of software engineering activities, actions or tasks. This generates the event analysis model correction which will trigger the analysis action from done state to awaiting changes state.

The concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities, actions or tasks. Events generated at one point in the process network trigger transitions among the states.

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

The Team Software Process Team working Process

One should make ensure that the team members of team software process team follow the TSP plan.It includes:
- Leading the Team
- Process Discipline
- Issue Tracking
The team leader is responsible for leading and guiding the team which includes the day-to-day direction of the work, protecting team resources, resolving team issues, conducting team meetings, and reporting on the work.
During process discipline, the team leader ensures that the engineers do the job the way they had planned to do it. In monitoring process discipline, the team leader should check that every team member records his or her process data, reports on weekly status, and produces quality products.
Another responsibility is issue tracking which ensures that all of the issues that the team.

- Communication
- Management Reporting
Communication is a key part of maintaining the team’s energy and drive and facilitating communication is a key part of the team leader’s responsibilities. The team leader is responsible for maintaining open and effective team communication.
Management should be informed about team status and performance on a regular basis.

- Maintaining the Plan
- Estimating Project Completion
Maintaining the plan is very important once the teams have completed the project launch and started on the job, the plan guides the work. It also provides a benchmark for measuring progress as well as means to identify problems that might threaten the project schedule.
TSP teams track progress against the plan every week using a method called earned value. With earned value, each task is assigned a value based on the percentage of
the total project estimate that is required for that task.

- Re-balancing Team Workload
- Relaunching the Project
Unbalanced workload can cause a team to be inefficient. Causes include normal fluctuation in engineering performance. Also, the most experienced engineers are generally involved in much more of the work than the team members with less experience.
Whenever teams find that the plan no longer helps them to do their jobs, they should relaunch their projects. Teams should also be relaunched when there are major changes in the work to be done or in team membership.

- TSP Quality Management
TSP shows how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

Team Software Process (TSP) - TSP Quality Management

Team Software Process (TSP) shows teams how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

ELEMENTS OF TSP QUALITY MANAGEMENT

- Preparing a quality plan.
- Identifying quality problems.
- Finding and preventing quality problems.

PREPARING A QUALITY PLAN
TSP make a quality plan based on the estimated size of the product and historical data on defect injection rates, they estimate how many defects they will inject in each phase. Once the engineers have estimated the defects to be injected, they estimate defect removal,again using historical data or the TSP quality guidelines which are based on the yield for each defect removal phase. Once the injection and
removal estimates have been made, the team can generate the quality plan.

IDENTIFYING QUALITY PROBLEMS
TSP provides many quality measures one of them being is by comparing the data for any module or component with the quality plan. TSP introduces a series of quality measures like: Process quality index—PQI.
- Percent defect free—PDF: Comparing the PDF curves for several similar projects. Where there are problems, the quality manager can look at data on lower level components to identify the source of the problem and recommend what the team should do about it. PDF plot can only be produced for an overall system or large component.
- Defect-removal profile: The defect-removal profile can be drawn for the system, each of its subsystems, any component, or even down to the module level.
- Quality Profile: The quality profile measures the process data for a module against the organization’s quality standards. The five quality profile dimensions indicate module quality based on data for design, design reviews, code reviews, compile defects, and unit test defects.
- Process quality index—PQI: is produced by taking the product of the five dimensional values of the quality profile to produce a single quality figure of merit. With PQI values above about 0.4, program modules are generally defect free.

FINDING AND PREVENTING QUALITY PROBLEMS
The TSP quality measures can indicate likely quality problems even before the first compile. Once the problems are identified, they can be prevented by:
- Monitor the module during test to see if problems are found and then determine the remedial action.
- Reinspect the module before integration or system test.
- Rework on the module to fix suspected problems.
- Redevelop the module.

Team Software Process (TSP) - Framework Activities and Phases

Team Software Process (TSP) scripts define elements of the team process and the following framework activities:

- LAUNCH
It reviews course objectives and describes the TSPi structure and content. It assigns teams and roles to students and describes the customer needs statement. It also establishes team and individual goals.
- STRATEGY
It creates a conceptual design for the product and establishes the development strategy and decide what will be produced in each cycle. Strategy makes initial size and effort estimates and establish a configuration management plan, reuse plan and risk management.
- PLAN
It estimates the size of each artifact to be developed. Planning also identifies tasks to be performed, estimates time to complete each task;, assign tasks to team members, make a weekly schedule for task completion and make a quality plan.
- REQUIREMENTS
Requirements analyze need statements and interview the customers, specify and inspect the requirements and develop a system test plan.
- DESIGN
It creates a high-level design, specify the design, inspect the design, develop an integration test plan.
- IMPLEMENT
Implementation uses the PSP to implement modules/units, creates detailed design of modules/units, reviews the design, translates the design to code, review the code,
compile and test the modules/units and analyze the quality of the modules/units.
- TEST
Testing builds and integrate the system. It conducts a system test and produce user documentation.
- POSTMORTEM
It conducts a postmortem analysis, writes a cycle report and produce peer and team evaluations.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. Scripts defines specific process activities and other more detailed work functions that are part of the team process.
TSP recognizes that the best software teams are self directed. Team members set project objectives, adapt the process to meet their needs, have control over schedule, and through measurement and analysis of the metrics collected, work continually to improve team's approach to software engineering.

Team Software Process (TSP) - Strategy and Objectives

The goal of Team Software Process (TSP) is to build a self directed project team that organizes itself to produce high quality software. The objectives of TSP are:
- The TSP is intended to improve the levels of quality and productivity of a team's software development project.
- Using TSP, organizations establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.
- Accelerate software process improvement by making CMM level 5 behavior normal and expected.
- Show managers how to coach and motivate their teams and how to help them to sustain peak performance.
- Build self directed teams that plan and track their work, establish goals, and own their processes and plans. To form a self directed team, you must collaborate well internally and communicate well externally.

A self directed team should do the following:
- understand overall goals and objectives.
- defines roles and responsibilities for each team member.
- tracks quantitative project data.
- identifies a team process appropriate for project.
- implementing strategy for the process.
- defines local standards.
- assess risk and reacts to it.
- tracks, reports and manages project status.

TEAM SOFTWARE PROCESS (TSP) STRATEGY

- Provide a simple process framework based on the PSP.
- Use modest, well-defined problems.
- Develop products in several cycles.
- Establish standard measures for quality and performance.
- Provide detailed role definitions.
- Use role and team evaluations.
- Require process discipline.
- Provide guidance on teamwork problems.

How does Personal Software Process (PSP) help in Improving Quality of the Product?

Software quality is gaining importance day by day and getting a zero-defect product is really challenging. Any defect in a small part of a large program could potentially cause serious problems. Thus, to produce high-quality large programs, every software engineer who develops one or more of the system's parts must do high-quality work. This means that all engineers must manage the quality of their personal work. To help them do this, the PSP guides engineers in tracking and managing every defect

Simple coding mistakes can produce very destructive or hard-to-find defects. This is particularly important since the source of most software defects is simple programmer
oversights and mistakes.To improve program quality, PSP training shows engineers how to track and manage all of the defects they find in their programs.

- The first PSP quality principle is that engineers are personally responsible for the quality of the programs they produce. The PSP provides a series of practices and measures to help engineers assess the quality of the programs they produce and to guide them in finding and fixing all program defects as quickly as possible. PSP quality management methods are early defect removal and defect prevention.

- The second PSP quality principle is early defect removal.The PSP process includes design and code review steps in which engineers personally review their work products before they are inspected, compiled, or tested. The principle behind the PSP review process is that people tend to make the same mistakes repeatedly.

- The third PSP quality principle is to prevent defects.There are three ways to prevent defects in PSP. First, engineers record data on each defect they find and fix and then review these data to determine
what caused the defects and to make process changes to eliminate these causes. Second, use an effective design method and notation to produce complete designs. Third, with a more thorough design, coding time is reduced, thus reducing defect injection.

The Personal Software Process (PSP) - Objectives and PSP Model

The developer uses some process to build computer software. The process can be ad hoc, may change on a daily basis, may not be efficient, effective or even successful, but a process does exist.
In the PSP methods included are: following a defined process, planning the work, gathering data, and using these data to analyze and improve the process.
While this sounds simple in concept, it is not easy in practice. This is why a principal focus of PSP introduction is on providing a working environment that supports PSP practices.

- PSP helps software engineers to understand and improve their performance by using a disciplined, data-driven procedure.
- PSP emphasizes personal measurement of both the work product that is produced and the resultant quality of the work product.
- PSP makes the practitioner responsible for project planning.
- PSP empowers the practitioner to control the quality of all software work products developed.
- PSP helps software engineers to improve their estimating and planning skills, make commitments they can keep, manage the quality of their projects, reduce the number of defects in their work.
- PSP helps developers produce zero-defect, quality products on schedule.
- PSP emphasizes the need to record and analyze the types of errors you make, so strategies can be developed to eliminate them.

FRAMEWORK ACTIVITIES USED DURING PSP ARE:
The PSP model defines five framework activities:
- Planning: Isolates requirements and based on these develops both size and resource estimates. A defect estimate is also made.
- High Level Design: External specifications for each component to be constructed are developed and a component design is created. Prototypes are built and all issues are recorded and tracked.
- High Level Design Review: Formal verification methods are applied to uncover errors in design.
- Development: The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested.
- Postmortem: The effectiveness of the process is determined using the measures and metrics collected.

The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

System Modeling - The Hatley Pirbhai Modeling

System models are hierarchical or layered as a system is represented at different levels of abstraction. The top level of hierarchy presents the complete system. The data objects, functions, behaviors are represented. As the hierarchy is refined or layered, component level detail is modeled and finally system models evolve into engineering models.
Hatley-Pirbhay modeling is an extension of the concept that every computer system can be modeled through the usage of an input-processing-output model by including the two additional features of user interface process and maintenance/self testing. These five components are added to a system model template to allow for modeling of the system which allows for proper assignment to the processing regions.

THE HATLEY-PIRBHAI MODELING
- The Hatley-Pirbhai model depicts input processing, and output along with the user interface and maintenance or self-test.
- It includes two more system features: user interface processing and maintenance and self-test processing.
- A system engineer can create a model of system components that sets a foundation for later steps.
- The system engineer allocates system elements to each of five processing regions within the template: user interface, input, system function and control, output, maintenance and self-test.
- A system context diagram(SCD) resides at the top level of hierarchy which defines all external producers of information used by the system,all external consumers of information created by the system and all entities that communicate through interface or perform maintenance and self-test.
- All the major subsystems are defined in a system flow diagram (SFD) which is derived from SCD.
- Information flows across the regions of system context diagram is used to guide the system engineer in developing system flow diagram.
- System flow diagram shows major subsystems and important lines of information.

Flow Oriented Modeling - Creating a Data Flow Model

Flow models focus on the flow of data objects as they are transformed by processing functions. Derived from structured analysis,flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Data flow oriented modeling is the most widely used analysis notation. Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification.

Steps to create a data flow model
- Diagram 0: develop a context diagram.
- Decompose the Process into high level processes.
- In parallel to this, develop data flow diagrams, entity relationship diagrams and state transition diagrams.
- Define data stores which includes normalization.
- Develop data dictionary.
- Finalize data flow diagrams, entity relationship diagram and state transition diagrams.
- Develop process specifications which includes PDL, decision tables or trees.
- Perform transformational analysis which includes developing structure charts.
Information flow continuity must be maintained as each data flow diagram level is refined. This means that input and output at one level must be the same as input and output at a refined level.

How do we map data flow into a software architecture?

In architectural design, the mapping method uses data flow characteristics to derive a commonly used architectural style. A data flow diagram is mapped into program structure using one of the two mapping approaches:
- Transform Mapping
- Transaction Mapping
Structured design is often characterized as a data flow oriented design method because it provides a convenient transition from a data flow diagram. This type of information flow is the driver for the mapping approach.
Transform Flow: The overall flow of data occurs in a sequential manner and follows one, or only a few straight line paths. When a segment of a data flow diagram exhibits these characteristics, transform flow is present.

Transaction Flow: Information flow which is characterized by single data item called a transaction that triggers other data flow along one of many paths. When a data flow diagram takes this kind of form then transaction flow is present.

TRANSFORM MAPPING

It is a set of design steps that allows a data flow diagram with transform flow characteristics to be mapped into a specific architectural style.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Isolate the transform center by specifying incoming and outgoing flow boundaries.
- Perform first level factoring.
- Perform second level factoring.
- Refine the first iteration architecture using design heuristics for improved software quality.

TRANSACTION MAPPING

In transaction mapping, information flow along two of the three action paths accommodates additional incoming flow. Each action path flows into a single transform, display messages and status. The design steps for transaction mapping is similar with a major difference lies in mapping of data flow diagram to software structure.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Identify the transaction center and the flow characteristics along each of the action paths.
- Map the data flow diagram in a program structure amenable to transaction processing.
- Factor and refine the transaction structure and the structure of each action path.
- Refine the first iteration architecture using design heuristics for improved software quality.

Once an architecture has been derived, it is elaborated and then analyzed against quality criteria.

Architectural Design - Refining the Architecture into Components and Describing Instantiations of the System

Refining the Architecture into Components

As the software architecture is refined into components, structure of the system begins to emerge. Components of the software architecture are derived from three sources:
- the application domain
- the infrastructure domain
- the interface domain
Because analysis modeling does not address infrastructure, one should allocate sufficient design time to consider it carefully.
In order to find the components that are most suitable for refining the software architecture, you need to start by using the classes which were described in the analysis model. The analysis classes in turn are representations of business entities that architecture is trying to describe. You could also base these components on an infrastructure model rather than the business model. If you went purely by the business model, you would not be able to depict many of those infrastructure components such as database components, components used for communication etc.
Whatever interfaces are described in the architecture context diagram imply one or more specialized components that process the data that flow across the interface.

Describing Instantiations of the System

The context of the system has been represented, the archetypes indicating important abstractions are defined, the overall structure of system apparent and major software components are identified, however further refinement is necessary which is accomplished by developing an actual instantiation of architecture. The architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

Architectural Design - Representing the System in Context and Defining Archetypes

As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.

REPRESENTING THE SYSTEM IN CONTEXT

Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.

How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.

DEFINING ARCHETYPES

Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller

What are different types of architectural pattern domains?

Architectural patterns define a specific approach for handling some behavioral characteristics of the system. A software architecture may have a number of architectural patterns that address issues such as concurrency, persistence and distribution.

CONCURRENCY
To promote parallelism, applications must handle multiple tasks and there are different ways to handle concurrency by an application and each way can be presented by a different architectural pattern.
- One approach is to use an operating system process management pattern that provides built-in operating system features allowing components to execute concurrently.
- Another approach is to define a task scheduler at the application level.

PERSISTENCE
Data persists if it survives past the execution of the process that created it. Persistent data can be read or modified by other processes at a later time as they are stored in a database or file. Persistence can be achieved through two architectural patterns:
- database management system pattern that applies the storage and retrieval capability of a database management system to the application architecture.
- application level persistence pattern that builds persistence features into application architecture.

DISTRIBUTION
The distribution problem addresses in a manner in which systems or components communicate with one another in a distributed environment. The most common architectural pattern established to address distribution problem is the broker pattern. Broker acts as middle man between client and server component.

What are different types of architectural styles?

Large number of computer systems are created. Some of the architectural styles are:

Data Centered Architecture
Data store resides at center of architecture and is accessed frequently by other components that update, add, delete or otherwise modify data within the store. A data centered architecture promotes integrability, which means existing components can be changed and new client components added to the architecture without concern about other clients.

Data-flow Architecture
Data flow architecture is applied when input data is to be transformed through a series of computational or manipulative components into output data. Pile and filter structure has a set of components called by filters connected by pipes that transmit data from one component to another. Each filter works independently. If data flow degenerates into a single line of transforms, it is called batch sequential.

Object Oriented Architecture
In this architecture, data and operations are encapsulated by the components of a system. Communication and coordination between components is done by message passing.

Call and Return Architecture
In this architecture, software designer achieves a program structure which is relatively easy to modify and scale. Two sub-styles exist: Main program/subprogram architecture and Remote Procedure Call Architecture.

Layered Architecture
In this architecture, different layers are defined. Each layer accomplishes operations that progressively become closer to machine instruction set. Components service user interface operations at outer layer. Components perform operating system interfacing at the inner layer.

What is an architectural style and pattern?

There are many architectural styles associated with the software that is built for computer based systems. The style describes a system category that encompasses:
- set of components.
- set of connectors enabling communication, coordination and cooperation among components.
- constraints.
- semantic models enabling a designer to understand overall properties of a system.

Architectural style is a transformation which is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. When an existing architecture is re engineered, fundamental changes to the structure of the software results.
Architectural pattern imposes a transformation on the design of an architecture. Differences between pattern and style are:
- Scope of pattern is less broad.
- Pattern imposes a rule on architecture describing how software will handle some aspect of its functionality.
- Architectural patterns tend to address specific behavioral issues within context of architectural.
Patterns can be used in conjunction with an architectural style to establish the shape the overall structure of a system.

How is data designed at architectural and component level?

Data Design at Architectural Level

Data design translates data objects defined during analysis model into data structures at the software component level and, when necessary,a database architecture at the application level.
There are small and large businesses that contains lot of data. There are dozens of databases that serve many applications comprising of lots of data. The aim is to extract useful information from data environment especially when the information desired is cross functional.
Techniques like data mining is used to extract useful information from raw data. However, data mining becomes difficult because f some factors:
- Existence of multiple databases.
- Different structures.
- Degree of detail contained with databases.Alternative solution is concept of data warehousing which adds an additional layer to data architecture. Data warehouse encompasses all data used by a business. A data warehouse is a large, independent database that serve the set of applications required by a business. Data warehouse is a separate data environment.

Data Design at Component Level

It focuses on representation of data structures that are directly accessed by one or more software components. Set of principles applicable to data design are:
- Systematic analysis principles applied to function and behavior should also be applied to data.
- All data structures and operations to be performed on each should be identified.
- The content of each data object should be defined through a mechanism that should be established.
- Low level data design decisions should be deferred until late in design process.
- A library of data structures and operations that are applied to them should be developed.
- The representation of data structure should only be known to those modules that can directly use the data contained within the structure.
- Software design and programming language should support the specification and realization of abstract data types.

Software Architecture Design - why is it important?

The architecture is not the operational software, rather it is a representation that enables a software engineer to analyze the effectiveness of the design in meeting its stated requirements, consider architectural alternatives at a stage when making design changes is still relatively easy and reduce the risk associated with the construction of the software.

- Software architecture enables and shows communication between all parties interested in the development of a computer based system.
- Early design decisions that has a profound impact on software engineering work is highlighted through architecture.
- Architecture constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together.

The architectural design model and the architectural patterns contained within it are transferable. Architectural styles and patterns can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.

Software architecture considers two levels of design pyramid - data design and architectural design. The software architecture of a program or computing system is the structure or structures of the system, which compose software components, the externally visible properties of those components and the relationships among them.

How do we create an architectural design....an overview

Design is an activity concerned with making major decisions, often of a structural nature. It is a multi-step process in which representations of data and program structure, interface characteristics, and procedural detail are synthesized from information requirements.

Architectural design represents the structure of data and program components that are required to build a computer based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system. A software engineer can design both data and architecture, the job is often allocated to specialists when large, complex systems are to be built. A database or data warehouse designer creates the data architecture for a system. The system architect selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.

Architectural design provides with the big picture and ensures that you have got it right in a same manner as before building a house, you need a blueprint. Architectural design begins with data design and then proceeds to the derivation of one one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.

An architecture model encompassing data architecture and program structure is created during architectural design. In addition, component properties and relationships are also described. At each stage, software design work products are reviewed for clarity, correctness, completeness, and consistency with requirements and with one another.