What is software architecture?

The software architecture of a program or computing system is a depiction of the system that aids in the understanding of how the system will behave. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision.

Is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

The Principles of Architecture Design

Your design will generally need to evolve during the implementation stages of the application as you learn more, and as you test the design against real world requirements. Create your architecture with this evolution in mind so that it will be able to adapt to requirements that are not fully known at the start of the design process.

Consider the following questions as you create an architectural design:

What are the foundational parts of the architecture that represent the greatest risk if you get them wrong?
What are the parts of the architecture that are most likely to change, or whose design you can delay until later with little impact?
What are your key assumptions, and how will you test them?
What conditions may require you to refactor the design?

Key Architecture Principles

Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.
Model to analyze and reduce risk. Use design tools, modeling systems such as Unified Modeling Language (UML),

Continue reading "What is software architecture?" →

What is software design?

Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. Software design may refer to either all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems.

For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms.

Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

Software Design Levels

Architectural Design – The architectural design is the highest abstract version of the system. It identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other. High-level design focuses on how the system along with all of its components can be implemented in forms of modules. It recognizes modular structure of each sub-system and their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs. It is more detailed towards modules and their implementations. It defines logical structure of each module and their interfaces to communicate with other modules.

Modularization

Is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently.

Concurrency

Is implemented by splitting the software into multiple independent units of execution, like

Continue reading →

Unified Modeling Language (UML)

UML specification defines two major kinds of UML diagram: structure diagrams and behavior diagrams.

Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts.

Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time. (the information is on http://www.uml-diagrams.org/)

Version	Date	Description
1.1	11-1997	UML 1.1 proposal is adopted by the OMG.
1.3	03-2000	Contains a number of changes to the UML metamodel, semantics, and notation, but should be considered a minor upgrade to the original proposal.
1.4	09-2001	Mostly “tuning” release but not completely upward compatible with the UML 1.3. Addition of profiles as UML extensions grouped together. Updated visibility of features. Stick arrowhead in interaction diagrams now denotes asynchronous call. Model element may now have multiple stereotypes. Clarified collaborations. Refined definitions of components and related concepts.Artifact was added to represent physical representations of components.
1.5	03-2003	Added actions (see Part 5 of spec) – executable actions and procedures, including their run-time semantics, defined the concept of a data flow to carry data between actions, etc.
1.4.2	01-2005	This version was accepted as ISO specification (standard) ISO/IEC 19501. UML 1.5 was released 2 years before.
2.0	08-2005	New diagrams: object diagrams, package diagrams, composite structure diagrams, interaction overview diagrams, timing diagrams, profile diagrams. Collaboration diagrams were renamed to communication diagrams. Activity diagrams and sequence diagrams were enhanced. Activities were redesigned to use a Petri-like semantics. Edges can now be Continue reading "Unified Modeling Language (UML)" →

Functional and non functional requirements

Any project’s requirements need to be well thought out, balanced and clearly understood by all involved, but perhaps of most importance is that they are not dropped or compromised halfway through the project. The difference is that non-functional requirements describe how the system works, while functional requirements describe what the system should do.

The functional requirement is describing the behavior of the system as it relates to the system’s functionality. The non-functional requirement elaborates a performance characteristic of the system.

Functional Requirements:

Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created.

Some of the functional requirements include:

Business Rules.
Transaction corrections, adjustments and cancellations.
Administrative functions.
Authentication.

Nonfunctional Requirements

Nonfunctional requirements refer to a whole slew of attributes including performance levels, security, and the various “ilities,” such as usability, reliability, and availability.

Some typical non-functional requirements are:

Performance.
Scalability.
Capacity.
Availability.
Reliability.

Refences:

http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/

http://stackoverflow.com/questions/16475979/what-is-functional-and-non-functional-requirement

Image from: http://www.slideshare.net/KhushbooShaukat/non-functional-requirement-41586605

Waterfall Model

The Waterfall Model was first Process Model, was first defined by Winston W. Royce in 1970 and has been widely used for software projects ever since. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

Waterfall model is the earliest SDLC approach that was used for software development. Despite the development of new software development process models, the Waterfall method is still the dominant process model with over a third of software developers still using it.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.
System Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.
Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.
Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions

Continue reading "Waterfall Model" →

Agile Programming

There’s a few ways of working when you’re involved when working in a software engineering environment. A big one is the agile manifesto. Although it sounds kind of weird, it’s a actually a quite straight forward way of working. In the manifiesto there’s 4 important values:

Individuals and interactions. To focus on the people that are working rather than int the processes or tools that are being used in the project.

Working software over comprehensive documentation. Personally I find this very important. In big projects that I worked before, my team and I couldn’t really deliver an optimal product due to the fact that documentation was in a bigger priority than the project itself.

Costumer collaboration over contract negotiation. Costumer interaction can be quite tricky some times. Some times, when a client asks for a certain product the people producing it can finish it, give it to the client but the client will have complains or will want to make changes to the now already finished product. Maintaining a constant costumer collaboration ensures that this kind of stuff doesn’t happen, there’s less time being wasted, and the client can be more satisfied with the result.

Responding to change over following a plan. Something that we can take for granted always is change. It’s very rare when something goes exactly how it was planned. Because of this, it’s really importante to keep a mindset ready for anything to change, so that the flow and work in the project is not affected so much.

Now, from this 4 values 12 principles came out in order to optimize the development of software.

Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business

Continue reading "Agile Programming" →

Software Development Processes

Software Development Processes is a set of steps that a software program goes through when developed.

First in the software development process, the requirements phase outlines the goals of what the program will be capable of doing. Next, the design phase covers how the program is going to be created, who will be doing what, etc. The implementation phase is where the programmers and other designers start work on the program. After the developers have a working copy, the testing and verification step can begin to help verify the program has no errors. During the testing phase, problems found are fixed, until the program meets the company’s quality controls. After the program’s development, the documentation phase on how to use the program can be completed. Finally, maintaining (updating) the program must continue for several years after the initial release.

A software development process makes everything easier and reduces the amount of problems encountered.

Software Development processes models:

The waterfall model: This is the classic SDLC model, with a linear and sequential method that has goals for each developmentphase. The waterfall model simplifies task scheduling, because there areno iterative or overlapping steps. One drawback of the waterfall is thatit does not allow for much revision.
Rapid application development (RAD): This modelis based on the concept that better products can be developed more quicklyby: using workshops or focus groups to gather system requirements; prototyping and reiterative testing of designs; rigid adherence to schedule; and less formality of team communications such as reviews.
Joint application development (JAD): This modelinvolves the client or end user in the design and development of an application,through a series of collaborative workshops called JAD sessions.
The prototyping model: In this model, a prototype (an early approximation of a final system or product) is built, tested,and then reworked as

Continue reading →

Ethics in software engineering

Software engineering ethics are a subset of engineering ethics and professional ethics applied to the design and development of software systems.

The ACM/IEEE-CS Code of Ethics and Professional Practice have a standard for teaching and practicing software engineering. In this code they have eight important principles witch are Public, Cient and employer, Product, Judgment, Management, Profession, Colleagues, Self.

in the sort version of the Code of Ethics these are the definition for the principles.

1. PUBLIC – Software engineers shall act consistently with the public interest. (You accept the full responsibility of the work that you do, You have to be honest)

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. (You have to talk with your client and employer, do not cheat, because you make a bad reputation)

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. (Don’t copy the code of someone else, don’t lie about it)

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.(selects what is best and do not go above others)

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.(If you are the leader of the develop team, be the ombudsman, do not lie, cheat, only be a good person)

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. (Don’t create problems for the community, because the other people will think that the programmers are bad and don’t work)

7. COLLEAGUES – Software engineers shall be fair to and supportive of their

Continue reading →

History of software engineering

The term software engineering begans in the 1960s. Writing software has envolved into a profession concerned with how best to maximize the quality of software and how to create it.Emergence as a profesion: by the early 1980s, to stand beside computer science and traditional engineering. In the software crisis of the 1960s, 1970s and 1980s, which identified many problems of software development. many of the projects ran over budget and schedule, a buch of project caused loss of life.The software crisis has been fading from view, because it is psychologically extremely difficult to remain in crisis mode for a protracted period.

Solving the software crisis was paramount to researchers and companies producing software tools.the cost of owning and maitaining software in the 1980s was trwice as expensive as developing the software. The rise of the internet led to very rapid growth in the demand for international information display/e-mail systems on the World Wide Web.

With the expanding demand for software in many smaller organizations, the need for inexpensive software solutions led to the growth of simpler, faster methodologies that developed running software, from requirements to deployment, quicker & easier. Software engineering is a young discipline, and is still developing.

More info: https://en.wikipedia.org/wiki/History_of_software_engineering

Software lifecycle

Software lifecycle is a process that ensures good software is built. Software lifecycle describe phases of the software cycle and the order in which those phases are executed, each phases produces deliverables requiered for the next phase. the code is produced according to the design wich is called “Development phases”.

The phases of the Software development life cycle are:

Requirement gathering and analysis
Design
Implementation or coding
Testing
Deployment
Maintenance

Requirement gathering and analysis

This phases is the main focus of the project managers and stake holders. Meetings with managers, stake holders and user is helpful to determine the requirements, after requirement gathering these reequirements are analyzed for the validity.

Design

the system and software design is prepared from the requirements specifications, helps in specifying hardware and system requirements.

Implementation or coding

Receiving system desing documents, here where the work begans, is divided in modules or units and coding is started. the code is produced so it is the main focus for the developer.

Testing

When the code is finished is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements pahse.

Deployment

after the succesful testing the prodcut is delivered tho the customer for their use. but a first step is to create the beta testing for the customer. any changes or bugs are caugth and report to the engineering team.

Maintenance

Once the customers stars using the developed system then the actual provlems comes up and need to be solved.

image from: http://ccm.net/contents/232-software-lifecycle

Here you can find more info…