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... 

Rams' ten principles to "good design"

Good design:
Is innovative - Rams states that possibilities for innovation in design are unlikely to be exhausted since technological development is always offering new opportunities for innovative design. He also highlights that innovative design always develops in tandem with innovative technology and can never be an end in and of itself.
Makes a product useful - A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it.
Is aesthetic - Only well-executed objects can be beautiful. The aesthetic quality of a product is integral to its usefulness because products used every day have an effect on people and their well-being.
Makes a product understandable - It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user's intuition. At best, it is self-explanatory.
Is unobtrusive - Products and their design should be both neutral and restrained, to leave room for the user’s self-expression. Products fulfilling a purpose are like tools and are neither decorative objects nor works of art.
Is honest - Honest design should not attempt to make a product seem more innovative, powerful or valuable than it really is. It should not attempt to manipulate the consumer with promises that cannot be kept.
Is long-lasting - It should avoid being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even when the trend may be in favor for disposable products.
Is thorough down to the last detail - Dieter Rams states that nothing must be arbitrary or left to chance in the design of a product since care and accuracy in the design process show respect towards the consumer.
Is environmentally friendly - Good design should make an important contribution to the preservation of the environment by conserving resources and minimizing physical and visual pollution throughout the lifecycle of the product.
Is as little design as possible - Dieter Rams makes the distinction between the common "Less is more" and his strongly advised "Less, but better" highlighting the fact that this approach focuses on the essential aspects thus, the products are not burdened with non-essentials. The desirable result would then be purer and simpler.

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)

Makeovers

Roughly a month ago i was hard at work, against time time and energies to integrate a whole new set of changes in the services with the UI. It was crazy to put it mildly and it was one huge chunk and it was evolving everyday. The whole transition to the new changes took a new 5 days to come to stable grounds. After i was done, i left for a week long break. I knew that the changes would continue, even from where i left off. When i came back however, change was made in virtually every way the application was conceived to begin with. The changes resulted in a drastic makeover and i was in no state to even comprehend the new dynamics of the business that were introduced in the software. I was truly lost. Makeovers are a part of any developmental process. But the big question is if they should be. At least by definition, they should not. A makeover is something that has to come after the development phase is over, instead of being a part of it. In the world of software, where the work and the daily text is  adorning the guises of programming languages, understanding the changes becomes even more difficult. One might argue that this is a common feature of any profession and is not specific or more so in the software world. But i tend to disagree here. Not because i am a part of this Industry of Logic, but because as a proponent of logic i can not help but notice that this industry is still young and is driven by a truly illogical set of rules and frameworks.

Read the rest of this post »

An SQL puzzle

Check out this little snippet of SQL: [sourcecode language="sql"] SELECT PRAMvtID, PRAMvtRALoadDteTme, PRAMvtRAStatus, PRAMvtRAType, PRAMvtRAApprvlStatus, PRAMvtCompany, PRAMvtDeliveryNetwrk, PRAMvtMeasurePoint, PRAMvtSalesMonth, PRAMvtTicketNo INTO #complete_tkts FROM PAPRAMovement d WHERE PRAMvtID IN (SELECT PRAMvtID FROM PAPRAMovement dd WHERE dd.PRAMvtCompany = d.PRAMvtCompany AND dd.PRAMvtDeliveryNetwrk = d.PRAMvtDeliveryNetwrk AND dd.PRAMvtMeasurePoint = d.PRAMvtMeasurePoint AND dd.PRAMvtSalesMonth = d.PRAMvtSalesMonth AND dd.PRAMvtTicketNo = d.PRAMvtTicketNo AND dd.PRAMvtRAStatus = 'C' ) [/sourcecode]

Read the rest of this post »