Filed under: Software Engineering

Goal based RE!

This is a recent paper i read on RE; Requirements Engineering in the Year 00: A Research Perspective (http://dl.acm.org/citation.cfm?id=337184).

And this was my response:

Overall while reading this paper, one could feel a sense of pity that we (software folk) allowed programming paradigms to drive the paradigms of RE. I am talking of Object Oriented techniques here. When clearly, it should have been the other way around. Goal based approaches including responsibility assignment and goal dependencies seem to be a far more natural way of doing things rather than relying on scenarios. And when grounded in formal methods such as AND/OR relationships they form the bridge to the implementation landscape thus driving software architectures and eventually programing.

History Slicing

History Slicing - Francisco Servant, James A. Jones. Proceedings of the 26th IEEE/ACM International Conference on Automated Software Engineering (ASE), Short paper track, Lawrence, Kansas, USA, November 2011, pp. 452–455.

This paper puts forth the concept of history slicing, a method which traces a part of the history of a subset of the code-base, which is of interest to the developer. This subset of history is called a history slice, which can then be used to understand the evolution of specific program features and design rationale, to carry out code forensics and for generating code based developer statistics.

This is done by building a history graph. Then, based on some form of selection criterion using which the lines to be investigated are chosen and the graph is traversed and the resulting slice is presented in an appropriate manner. This paper provides us with this bare minimum base upon which different methods for the steps described, can be used. The paper at every stage starts with a concept explains an adaptation for implementation and moves on to the next concept, thus giving a complete overview of the idea without dwelling deep into a specific direction, full of specific details. Many might view this as a folly, I do not. This in my opinion is a good basic start to novel subject.

However, the method that the authors select for building such a graph, in my view, is too simplistic. Each node in the graph, which represents a line of code, is allowed to be connected only to one node in the previous revision of the code and/or to one in the next revision of the code. This view seemingly ignores the idea of a single line of code being written or broken down to more than one line or vice versa. E.g.,int x= 10; can be split into the following two statements: int x; x=10; (semicolons represent end of a line)

Moreover, the idea of mapping the lines of code between two revisions is based on Diff, a tool which was originally meant for comparing files containing English text, not code. All this is done using the Levenshtein edit distance which calculates the difference between the lines using character analysis. In all this, we have missed out considerably on the semantic differences between the lines of code. As noted by Hunt and Tichy [1], conflicts between two versions of the code are generally identified using the notion of collocation, i.e. if two changes occur at the same point in a file. They further inform us with a more exact definition of conflicts based on the notion of semantic interference, i.e. if a change in one revision affects the results of a change in another revision. Semantic interference may not always be collocated.

The authors need to redefine their goals for history slicing which is based on syntactic comparison of line of code. This current approach to history slicing is good for informing developer statistics or for a line-by-line approach to code forensics. However, you require an approach more based on a semantic analysis of the code, when it comes to understanding the design rationale or evolution of the code base.

The evaluation of this method is based on a “Manual vs Automatic” study. The results of the study however, do not inform us of the differences in the history slices produced by the Manual and Automatic approaches. Did such differences, if present, have anything to do with the time taken? Was there a difference in approach between the two? It is fair to say that developers will use semantic contexts for generating history slices, which is not what the proposed method for building history graphs does?

The paper opens a novel concept for future study and exploration. However, it needs to revise the problems that it wants to solve using the approach presented. Also, the authors might consider automating the calculation and usage of a program slice as a selection criterion for creating a history slice.

[1] J. Hunt and W. Tichy. Extensible Language-Aware Merging. IEEE International Conference on Software Maintenance, 0:511–520, 2002.

The 2nd Time Dimension of the Vee SDLC Model

So i was reading about the vee-model today as a part of my readings for the SE class i am taking this term. The model was developed by NASA and it made a lot of sense to me, with the feedback between the various stages of the development prcosses across the two legs of the V. And then i got to the part where it spoke of time being represented on two axeses: the x and the z.

That is when i stopped, and opened by editor to jot down this post. Why would you want to represent the same quantity over two different dimensions, especially when they are representing the same thing?

The v- model, being three-dimensional, also has an axis that is normal to the plane, the z-axis. This represents components associated with multiple deliveries. Time is therefore represented by two axes: from left to right and into the plane.

- Ruparelia, N. B. (2010). Software development lifecycle models. ACM SIGSOFT Software Engineering Notes, 35(3), 8. doi:10.1145/1764810.1764814

So as pointed out by Ruparelia above, the z-axis is to showcase the multi deliverable software. One direct idea that comes to mind when you read this is that if the software was to be delivered multiple times, then it would be reasonable to assume that it the deliveries are to happen sequentially. And hence, the same V can be repeated in the Y-axis. Thus giving a more streamlined and uniform picture of the history of deliveries of the software.

Such an axis would make sense if, the same lifecycle were to be repeated in nearly the same time span, but in parallel for many deliverables of the same product. Now, i don't know if such a thing would even be possible. But to me it only makes sense then.

That being said, I am open to hear out other ideas and explanations for this 2nd dimension of time.

Review on Foundations for the Study of Software Architecture, Dewayne E. Perry and Alexander L. Wolf

This paper gives the foundation of Software Architecture, in a very methodical manner. Well established architectural fields are analyzed to make an intuitive case for software architecture. While one would expect this to be an exploratory paper, based upon its title, it is has actually followed the problem-solution-validation model[1] for writing good software engineering research papers. This is followed by providing a context for the role of software architectures, and then by the problems they intend solving using a formal model for software architecture, which is proposed in the paper. This is model is validated based on the popularly accepted architecture of the compiler as an example.

This paper, showed software architecture as a bridge between system requirements and design, with the notion of Form in its {Elements-Form-Rationale} Model, which is over and above the common notion of the notion of just the Elements – a framework to effectively develop programs in a large system. This actually allowed for the requirements to be showcased in an organized manner via the architecture, thus, assisting in refining and consolidating the requirements themselves, even though the paper doesn’t state it.

The discussion of architectural styles, specifically about how the architecture of one product can be taken up as the architectural style of another product was fundamental. This allows, extension of existing products, on top of their architecture or framework towards a better or newer products with a different functionality, thus invoking the idea of extensibility. e.g., The development of new tools and apps using the framework of APIs provided by various social networking platforms.

While discussing the benefits of software architectures, the managerial basis for cost estimation and process management has not been discussed substantially. A remote reference can be found in the compiler’s parallel architecture description, as to how application oriented properties were an indicator the system’s complexity and thus be co-related with cost. No other substantial points were discussed.
________________________________

[1] Mary Shaw, Writing Good Software Engineering Research Papers Minitutorial

Requirements Engineering

"In my debate team during undergrad i had a senior who told me that the issue with most debaters is not that they cannot speak to put forward their point. Their issue is that they do not know which point(s) to put forward."

To know what is required, in order to achieve an over all goal is probably the most difficult thing to do in any area of work. IEEE610, 1990: a requirement (in the context of software engineering) is a condition or capability which allows users to solve problems or achieve a goal.
Requirements Engineering is a phase in which the effort is to understand the problems(requirements) to be solved(satisfied) in order for us to arrive at a solution(working software system).  
The 'user' here may reffer to many different kinds of people:
a) the end user
b) the customer who pays the bill for the software
c) other stakeholders in the system.
Most requirements come from the end user for whom the software is finally meant for use. Other requirements are stated by the various other stake holders.
The word 'requirement' itself is a misnomer. A requirement is always given and cannot change once stated. But the world of software engineering, where software has to evolve, does not allow such a luxury. There are many factors changing the requirements of any project, such as:
a) Time to market,
b) Cost,
c) Conflicts in quality standards,
d) Conflicts in stakeholders' needs, etc.
These factors compel a trade off between the requirements that evolve and/or are in contention.

REQUIREMENT SPEC - The Document
a) The net requirements for any project are recorded in a document called REQUIREMENT SPEC. 
b) A requirement specification is, in an ideal world, the end product of the Requirements Engineering Phase.
c) It serves as the contract, formal/informal, between the client and the analyst; directing them towards a clear understanding of the problem at hand and thus, a solution to the same.
d) A high level design document:
It serves as the pivot around which the Design of the system is created. There can be no distinction between Requirements engineering and design as the two are deeply intertwined with each other. The reqs are viewed as a high level design of the system, based on which an overall design of the system is constructed. This design then consists of various components and the interfaces via which the components interact. This design is again used in creating a refinement of the requirements themselves. Such a process is greatly observed when prototyping techniques are used in building software. The two phases inherently revolve around each other in the case of agile methods of software development, where the two are constantly evolving in the presence of working system/solution.
Requirement Engineering and Design are presented distinctly, as consecutive stages of software development only for the sake of convinience.
e) The req spec is finally used in the acceptance testing of the system, when the working system is pitted against the req.spec. to validate and verify the system with the requirements.

REQ.ENGG. & ITS EXTENT 
Requirements engg is more than a simple analysis of the requirements of the system to be built. It is an iterative and co-operative process of: 
i) Analyzing a problem; 
ii) Recording the observations of such an analysis; 
iii) Checking/validating the understanding gained by the above two steps.

Furthermore, it is also goes beyond the idea just of recording requirements. It also encompasses the social and cognitive elements in the process of understanding the problem domain.

ELEMENTS OF REQ.ENGG.
Req engg contains a few fundamental facets to it: 
1) The most obvious of these happens to be the outlining of end-user requirements. Without these, this phase is useless and not complete. 
2) This being said, there are other functional requirements which emerge from stakeholders apart from the 'end user'. These are generally the managers and the administrators of the system. For instance, a manage would like to see how effective the system is on solving the problem for which it was created in the first place. An administrator may have to manage more functions such as managing user privilleges, maintaining proper logs of the system, etc. Such tasks are not required for a regular user of the system and hence they do not figure in the core feature list of the system.
3) Non-Functional Requirements: these requirements emerge from how the system will interface and interact with its enviroment. The system will have to interface with existing systems in order to fit into an existing infrastructure of solutions. For instance, in an online shopping store the product catalog will have to interface with existing check out and order management systems in order to give the customer a complete shopping experience. The product catalog, while being a self suffucient system in itself, alone cannot be effective when it comes to selling products online. The other set of requirements are to do with how the system interacts with the infrastructure on which it is deployed. Will respond well to a certain DBMS or an OS are important considerations which need to be accounted for. How will the system fare on various such technology stacks? What are the costs involved in maintaining such a system? How will the system scale as the data it manages acrues? 

While the 3rd set of requirements, the non-functional requirements, do not seem that important, it is essential that such things are looked with gross seriousness right from the very beginning. Sometimes this alson is the difference between successful and failed products.

GROUND REALITIES:
Apart from the above mentioned cats. of requirements and their sources, there are other ground realities about developing software:
1) Like we have seen time and time again, SOFTWARE EVOLVES because the REQUIREMENTS CHANGE. You cannot predefine a set of requirements and call it a day. Even is domains where the analyst is experienced, there can and will always be variations which need to be taken of care of effectively. These variations are in essence subtle and minor and thus go un-noticed. But their impact on the system is much larger and many-a-times at a very fundamental level. If such subtle changes in the requirements, especially in a 'known' domain, are not taken into account, then you are asking for trouble.
2) No one these days is interested in telling you what they want by going into the technicalities of things and solutions. What they are interested in is the final solution or product. Thus, unlike before where the customer/end-user and the analyst would discuss and outline the requirements, most requirements these days are derived out of market forces. In simpler terms, the process of requirement engg has now become market-driven rather than customer driven, more so anyway.
3) Also, you might decide to use COTS (commercial off the shelf) components for the building of the system, which might have its own set of constraints which will ultimately effect the requirements.
4) There are differences of opinion among various shareholders as well, which lead to a negotiation of requirements between the stakeholders and the analyst.

The Iteration cycle in requirement engg.: Elicitation -> Specification -> Validation -> Negotiation -> Elicitation... 

Parameters of Project Control

Time: time estimate largely depends upon the size of the project itself. the larger the project more time will it take to complete the project. the time frame can be reduced partially by increasing the work force allocated to the project. However, there will always be a trade off between the number of people and time. why should this matter though? simply because, an increase in the number of people requires an increase in the management overheads in contoling all the people resource effectively. Also after a point the increase in the number of people starts to have a counter effect on the time required to complete the project. It can almost be argued that increasing the work-force on a project delays the project more often than not.
Organization: the organization of a team is of great importance for successful projects. If every member clearly knows what to do (and more importantly why he/she is to do it) then the positive results seen in the development of the project are more than evident. In an event that this has not been conveyed clearly, there is no proper sharing of responsibility with a project team which only induces delays and poor quality of work. Also, it leads the members of the team to set their own goals, which has its own obvious repercussions.
Quality: No one is interested in the technical know-how of any product. Ultimately, the product should work. I.e., it should end up doing what it is supposed to do in the right manner and at the right times. This is where the concept of quality and quality assurance stems from. This is best achieved my ensuring high standards of quality at every stage of the product development. it should never be a one time affair, which is done once the implementation phase is at a close. This is how quality is incorporated into any product as its fundamental feature rather than an add-on. ("the quality requirements for software and for its development process are often in conclict."??) 
Money: A very fundamental dimension of project control. Expenses are largely decided by the labour force emplyed and it calculated in terms of man-hours. this (read labor force) is turn is evaluated on the basis of the size of the project. However, there are other factors that need to be taken into account while making cost estimations of software. Hardware and material resources are one set of things which require expenditures (these are small and very precicely calculatable). since the fundamental premise of expenditure is still labour, many labor cutting methods have been employed. These include use of tools and techniques for improved productivity, use of existing code bases to build new products, etc. Such techniques, while do cut on labour costs, have costs and expenditure of their own. Thus, in a convoluted manner, the software development slowly starts to become a cost-intensive proposition rather than a labor intensive proposition. 
Information: This comes in the form of documentation. and not only technical or user documentation but also project documentation which includes information pertaning the current state of the project, various changes agreed upon and decisions made.

What is Software Engineering?

1. It is to do with development of Large Systems.
2. The central theme is to master complexity. This complexity is to do with the existence of too many simple components rather than a few or a single component based on a sophisticated algorithm.
3. You are trying to model reality. In most cases it (read reality) is an existing manual process.
3.1. Software evolves like any reality.
3.2. The Software's efficieny is of great importance (as it models a reality).
3.3. Software has to support its users effectively. (this is highly implied!)
4. Co-operation is a key requirement between the parties and people developing software.
5. Members of one culture create artifacts for the members of another culture. eg: Most SE'ers are not bankers but then they do create banking/eCommerce systems.
6. It is a balancing act between that of an art and engineering.
REF:(6:31 PM 7/27/2011 Hans Van Vliet SE Principles and Practice)

Hardware v/s Software: Replacing Faulty Components

1. I stumbled upon an interesting difference between hardware and software today. Hardware errors are percieved to be random. I.e. when a hardware failure takes place, there is an implicit assumption that some component gave way to such an error or failure. And thus a simlpe replacement of that hardware equipment with an identical hardware component does the trick, or so is the assumption. This later assumption is true is most cases.
2. That being said, software works differently. The errors in Software are not due to a random faliure in its workings, simply because software unlike hardware is built on logical elements. Such faulty/error-inducing logic will replicate itself at all places where the software is used. Thus a simple replacement of software with its identical copy is of no use. Rather a specific modification of the logical workings of the software needs to be introduced for the software to function properly. 
3. Personal Obervation: This shows the contrast in the gap between the design and production elements, when it comes to hardware and software. This gap is huge when it comes to hardware: the design rarely has a direct impact on the workings of the hardware. Or rather the workings of the hardware depend on more factors than the design itself. Where as in the case of software, the desgin is so tightly coupled with the product itself that there does not seem to be any other reason for failure, other than design faults. This is assuming that the design was properly translated to the product in both cases. 
REF:(2:55 PM 7/27/2011 Hans Van Vliet SE Principles and Practice)