Software requirements

Software development consists of many knowledge-intensive processes. One of the most difficult to model, however, is requirements elicitation. This paper presents a mathematical model of the requirements elicitation process that clearly shows the critical role of knowledge in its performance. One meta-process of requirements elicitation, selection of an appropriate elicitation technique, is also captured in the model. The values of this model are: (1) improved understanding of what needs to be performed during elicitation helps analysts improve their elicitation efforts, (2) improved understanding of how elicitation techniques are selected helps less experienced analysts be as successful as more experienced analysts, and (3) as we improve our ability to perform elicitation, we improve the likelihood that the systems we create meet their intended customers’ needs.

Requirements elicitation is recognized as one of the most critical, knowledge-intensive activities of software development; poor execution of elicitation will almost guarantee that the final project is a complete failure. Since project failures are so rampant, it is quite likely that improving how the industry performs elicitation could have a dramatic effect on the success record of the industry.

To better understand the importance of the current paper, let us contrast its goal with the goal of the many dozens of writings, e.g., that present a specific methodology for elicitation broken down into multiple steps.

In this paper we use specific definitions for some terms:

Requirements Process. The activities that when performed result in an understanding and documentation of the desired external behavior (i.e., the requirements) of a system.
Process Model. A representation showing the processes to be performed in order to achieve some well-defined goal.
Technique. A documented series of steps along with rules for their performance and criteria for verifying completion. A technique usually applies to a single process

Continue reading "Software requirements" →

Software design patterns

Is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Design patterns are composed of several sections. Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern.

Types of software desing patterns

Algorithm strategy patterns: Related to high-level strategies describing how to exploit application characteristics on a computing platform.
Computational design patterns: Related to key computation identification.
Execution patterns: Which address issues related to lower-level support of application execution, including strategies for executing streams of tasks and for the definition of building

Continue reading "Software design patterns" →

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)

HISTORY OF UML

The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method.

As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.

The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required.

A UML is a diagram that includes a collection of elements such as:

Programming Language Statements
Actors: specify a role played by a user or any other system interacting with the subject.
Activities: These are tasks, which must take place in order to fulfill an operation contract. They are represented in activity

Continue reading "Unified Modeling Language (UML)" →

Ethics in SE

A code of ethics is a set of rules used as a guide for companies to demonstrate the expected behavior from the employees. The main purpose of these regulations is to conduct employee’s actions in accordance with values and ethical standards (Business Dictionary, 2016). In software engineering, it is almost the same rules that are applied to every software company with just a few variations.

This code of ethics was created by the Association for Computing Machinery in association with the Institute for Electrical and Electronics Engineers. Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

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.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

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

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

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" →