Friday, August 12, 2011

Introduction to WIX (Windows Installer XML)

Recently I have got an opportunity to work on creating installers for some of our products. In past I never got involved in post development activities but during my current job I spent some time in development related to deployment.
I have discovered there is a whole world out there to explore. Even the tip of the ice berg is quite vast.
Initially I created installers based on MSI technology using Visual Studio. However, I experienced that the approach was not friendly when it come to incorporate some product changes in installer. This is because we need to recompile the entire project and subsequently do some changes to resultant installer via orca. Addition/updation is a very common requirement in the web-based products we sell. For example, sometimes there is a small change like css update of an image/icon changes. This approach, which I was using required someone to rebuild the Visual Studio project which implies that visual studio is present on the machine. In addition, another dependency exists in the form of a person who knows visual studio and has some experience of creating installers.
Eventually a need of such an approach was felt which could free us from such dependencies.
The research resulted in the discovery of Microsoft WIX (Windows Installer Xml). WIX which is based on MSI technology allows us to descriptively create installers using XML files. There are tools through which people only specify the folders that need to be part of the installer and facilities are available to almost do whatever that is necessary while creating installer. Plug-ins are also available to integrate WIX with visual studio.
However, it must be kept in mind that the learning curve is quite steep. To facilitate people who are interested in learning WIX, I am listing some of the resources that I found useful. I will be adding some more resources to the list after filtering the collection I have

Creating WIX Installer for ASP.NET Web Application
http://www.codeproject.com/KB/install/asp_wix.aspx

From MSI to WiX
http://blogs.technet.com/b/alexshev/archive/2008/02/10/from-msi-to-wix.aspx

WIX Tutorial
http://wix.tramontana.co.hu/tutorial

Logging in IIS 7

Location of Log file:
%SystemDrive%\inetpub\logs\LogFiles

Pre-Requisite of Logging:
On Windows Server 2008 R2, following role service must be installed (In other Windows OS the following module must be enabled)
• Http Logging

Enabling and Disabling Logging:

If the pre requisite is installed the “Logging Icon” will appear in the “IIS” category of IIS Manager ([Server] Home Screen)
By default it is enabled, however it can be disabled or other configuration can be changed

References:
http://www.itsolutionskb.com/2009/10/how-to-find-iis-log-files/
http://technet.microsoft.com/en-us/library/cc754631(WS.10).aspx

Monday, August 1, 2011

AnjLab Profiler and “master.mdf…trc” files

SQL Profiler is a very useful tool to trace the execution of instructions over a database, however , it is not available for express edition of SQL Server databases
An alternate for this is a profiler from AnjLab which provides features quite similar to that of SQL Profiler.
Both SQL Profiler and AnjLab Profiler make use of the “Trace” facility available in the database engine of SQL Server.

Overall this profiler is harmless, however, there are two issues that must be considered when using the profiler

1. The profiler creates “master.mdf..yyyy.mm.dd.hh.min.sec.trc” file but (at least in our case it) does not delete the file when tracing is finished. These files are created in the default “DATA” folder of SQL Server instance (in our case). Since the files are not deleted automatically therefore a number of trace executions consume a lot of valuable space

2. In our scenario, if the profiler executes for a long time then it starts going into “Not Responding” states. Eventually the user is forced to close the application. In this case the “Trace” in SQL Server is not deleted thus it continues to execute and keeps on creating files unless explicitly closed using “sp_trace_setstatus”. (For more information on finding, stopping and closing traces see the article in this blog “SQL Server Trace Files Consuming Lot of Space”).

Wednesday, July 6, 2011

SQL Server Database becoming unavailable

Recently one of our Client went through a situation in which databases were becoming unavailable. We investigated the problem and searched for possible solutions.
Here is the summary of the activity

Findings

The error found in the client's database server log is
“FCB::Open: Operating system error 32(The process cannot access the file because it is being used by another process.)”
Other messages do not seem to be suspicious
There are three popular causes of this error
Abnormal Shutdowns:
In case system abnormally shuts down due to power failure or was forced to shutdown due to a “Not responding state”, operating system processes like “Write caching on device” are not completed properly and some files are not released.
Due to this some databases are shown as suspect on restart
Solution:
Uncheck the “Enable write caching on device”, which can be found in settings of partition/drive. The settings can be opened via the Hardware Tab which gets displayed when properties are of the drive are accessed
MDF Files Used by other Processes:
There may be antivirus or backup routines scheduled on the system. SQL Server starts a particular database when it is accessed by users. In case when MDF or LDF file is already in use by an anti-virus scan or backup schedule, then the operating system does not allow SQL Server to use the particular database file
Solution:
Exempt Database files from anti-virus scans or schedule scans and backups at a time when Database is not in use
Note: Process Explorer is an off-the-shelf tool that can be used to investigate which processes are actually using/locking particular file.

Limited privileges to Logon Account:
Some technical resources suggest that the problem may be due to limited privileges to log-on account
Solution
Grant privileges to the Logon account so that it is able to access LOG folder of MS SQL Server

Saturday, June 11, 2011

SQL Server Trace Files Consuming Lot of Space

Recently we faced a situation in which Hard Drive of one of our server machines was getting filled up. Investigation resulted in the discovery that a large number of trace files were being created
Initial study developed an opinion that it was due to default trace, however a formal study resulted in the finding which have been listed in the form of following Q/A.
Note: Information Applies to SQL Server 2005 and later versions

WHY DEFAULT TRACING IS DONE?
Supply auditing and performance data to reports available through the Management Studio Object Browser. E.g. Schema change history report [1]
HOW CRITICAL IT IS?
It depends upon the scenario. The best approach is to see the information being recorded in the trace to determine whether the information is suitable for you or not [2]
HOW RESOURCE GREEDY IT IS?
“The default trace is composed of five 20 megabyte trace files that are accessed in a round robin fashion, When the first file is full, the trace moves to the next file in the sequence. When the fifth file is full, the first file is deleted and a new file is created” [1]
In case a lot of space is consumed and a lot of files are being created then there is a possibility that other traces are running as well.
HOW TO FIND OUT WHAT TRACES ARE RUNNING?
The following command can be used [3]
SELECT * FROM fn_trace_getinfo(default);
GO
HOW TO STOP A TRACE?
Information regarding stopping a trace can be found in [2],[4],[5].



REFERENCES
[1] Audit SQL Server with the Default Trace, July 2007, Online: http://www.sqlconsulting.com/news1007.htm, Accessed: 07 June 2011
[2] Kadlec, J. Default Trace in SQL Server 2005, MSSQL Tips, November 2006, Online: http://www.mssqltips.com/tip.asp?tip=1111, Accessed: 07 June 2011
[3] fn_trace_getinfo (Transact-SQL), MSDN, http://msdn.microsoft.com/en-us/library/ms173875.aspx Accessed: 07 June 2011
[4] sp_trace_setstatus (Transact-SQL), MSDN, http://msdn.microsoft.com/en-us/library/ms176034.aspx, Accessed: 07 June 2011

Saturday, May 28, 2011

List and Definitions of Each UML Diagram

Use Case Diagrams
The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.
A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. As you discuss the functionality and processes of the system, you discover significant characteristics of the system that you model in the use case diagram. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system
http://www.developer.com/design/article.php/2109801/Creating-Use-Case-Diagrams.htm

Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency.[1] In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

http://www.answers.com/topic/activity-diagram

Class Diagrams:
A UML class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.
http://www.developer.com/design/article.php/2206791/The-UML-Class-Diagram-Part-1.htm

State Diagrams
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of a component in a system. The states are specific to a component/object of a system.
A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events.
http://www.tutorialspoint.com/uml/uml_statechart_diagram.htm

Interaction Diagrams
Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. The diagrams show a number of example objects and the messages that are passed between these objects within the use-case.
Interaction diagrams come in two forms, both present in the UML. The first form is the sequence diagram. In this form objects are shown as vertical lines with the messages as horizontal lines between them. This form was first popularized by Jacobson.
The second form of the interaction diagram is the collaboration diagram. Here the example objects are shown as icons. Again arrows indicate the messages sent in the use case. This time the sequence is indicated by a numbering scheme. Simple collaboration diagrams simply number the messages in sequence. More complex schemes use a decimal numbering approach to indicate if messages are sent as part of the implementation of another message. In addition a letter can be used to show concurrent threads.
http://www.cs.unc.edu/~stotts/145/CRC/Interactions.html

Sequence Diagram
A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects.
http://www.developer.com/article.php/3080941

Collaboration diagram
A Collaboration diagram is easily represented by modeling objects in a system and representing the associations between the objects as links. The interaction between the objects is denoted by arrows. To identify the sequence of invocation of these objects, a number is placed next to each of these arrows.
http://www.developer.com/article.php/3102981

Package diagram
A package provides the ability to group together classes and/or interfaces that are either similar in nature or related.
http://www.developer.com/design/article.php/2206791/The-UML-Class-Diagram-Part-1.htm Package diagram shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules.
http://www.visual-paradigm.com/VPGallery/diagrams/Package.html

Component Diagram
The component diagram's main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as files and executables. Unfortunately, this conflicted with the more common use of the term component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules. But, unlike UML 1.x, components are now strictly logical, design-time constructs.
http://www.ibm.com/developerworks/rational/library/dec04/bell/

Deployment Diagram
The Deployment Diagram also helps to model the physical aspect of an Object-Oriented software system. It models the run-time configuration in a static view and visualizes the distribution of components in an application. In most cases, it involves modeling the hardware configurations together with the software components that lived on.
http://www.visual-paradigm.com/VPGallery/diagrams/Deployment.html
Deployment diagrams are used to represent the physical architecture of a system. They present the distribution of the software components on the set of execution units (nodes).
Nodes and artifacts are the main concepts in a deployment diagram.
http://support.objecteering.com/objecteering6.1/help/us/objecteering_uml_modeler/diagrams/deployment_diagrams.htm

Tuesday, May 24, 2011

Notes on Scrum from MSF for Agile Development

Points Extracted from documents available at the site of MSF for Agile


MSF for Agile Development:
• Based on Scrum, the objective of which is to “Deliver MORE value FASTER”.
• Provides customers with the opportunity to review, guide and influence your team's work as it progresses
• Based on the idea of refining plan as the team makes progress.

About Scrum:
• Methodology based on Agile Principle
• Does not attempt to define everything at the start of project, instead team works in short iterations (sprints) to refine the plan and deliver value to customer.
Major Roles Involved:
• Team Role: Most individuals are in the Team Role
• Product Owner Role: Has the responsibility that ensures that your customers are represented on the team. Must have good knowledge of customer requirement
• Scrum Master: Ensures that the scrum practices are adhered to. E.g. ensures length of scrum meetings is less than 45 min. ensure that team does not include incomplete user stories in a sprint. Ensure that product owner does not add new features to the running sprint.

Activities in Scrum:
• Prepare for the project
o Establish business case
o Assemble Team (Assign three roles to people. Two people of the team will have additional responsibility, one will be Scrum Master and other will be Product Owner).
o Set up your team’s infrastructure. (Acquire and configure the necessary software for supporting scrum).
• Plan the project
--o High level plan will be established
--o It may change during implementation
--o Output of the process is Product Backlog
----- Backlog is a list of user stories (A description of user needs and user values) (By Team)
----- Prioritized by business value and risk (By Product Owner)
----- Estimation of user stories is done in abstract units called story points. (Story points are relative values that do not translate directly into a specific number of hours. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later) (By Team)
---- It is important that velocity is determined before planning (Velocity= total number of stories that can be covered in a sprint)
--o Output also includes Release Plan (If needed)
---- Identify groups of user stories that, together, provide enough business value to release to your customers.
---- Determine in which sprints the team expects to complete those groups of user stories.
--o Prepare for the first sprint
---- Sprint is a timeboxed iteration
---- One to Four (1 to 4) weeks long
---- Product Owner breaks the user stories down into smaller stories.
---- Product owner provide details about the user stories that the team will need to break the stories down into tasks.
---- Your team will also ask for details about the user stories to be able to break them down into tasks and estimate those tasks
• Plan a sprint
--o Sprint planning meeting
---- Team commits to completing a set of user stories from the product backlog
---- Sprint backlog is created which consist of
• Details regarding each task
• Actual hours to be spent for each task
• Total days to be consumed for a sprint
--o Choose user stories
---- Based upon the priority, user stories will be chosen for a particular sprint
---- Choice should be made based upon velocity of team
--o Identify tasks
---- Team determines the tasks it must perform to complete the story
---- They break the user stories to understand them and have confidence that it can be completed
--o Estimate Tasks
---- The Team decides how long (in hours) it will take to complete each task.
--o Commit to user stories
---- Uses iteration backlog to see if they have enough time
---- If less time is available then lower ranked user stories should be removed
• Run a sprint
--o Complete User Stories
---- Each member of your team signs up for a task when the sprint starts
---- After completing that task, the team member updates its status and sign up for another task
--o Track sprint progress
---- Daily scrum meeting of 15 minutes to maximize its chance of meeting commitments
• What I have done till last scrum meeting
• What I will do before the next
• What are the blocking issues.
--o Finish the sprint
---- Make sure that your team is completing all user stories or requirement (see if acceptance tests are being cleared )
• Track the project
--o Prepare the next sprint
--o Track release progress

Product Backlog:
• Consists of User Stories to represent what its customers need and value
• For each story the following information must be recorded
--o Who is the user
--o What the user needs to do
--o Why the user needs to do that.
• General Template: As a , I need to in order to
• Users stories should possess the INVEST characteristics
--o Independent
---- Able to be scheduled and implemented in any order
--o Negotiable and Negotiated
---- Details agreed upon with the customer
--o Valuable
---- Must be valuable to the Customer. When splitting stories for development it must be made sure that it should deliver value to customer. For e.g. designing middle tier
--o Estimable
---- Rough estimation
---- Smaller and negotiable things are easily estimated. Being Negotiable/Negotiated implies that a story is properly understood by the team.
--o Small
---- Story descriptions should be concise.
---- Stories themselves should be small and should worth not more than four person weeks of work
--o Testable
---- An important feature that can double check the clarity of requirement
---- If client does not know how a feature will be tested then he is not clear
• Low priority user stories can be kept large and can be detailed out when approached

Sprint Planning Meeting:
• 2-4 hour meeting
• Only once in a sprint
• Determine What to do in coming sprint
• Team builds Sprint Backlog on first day of sprint based upon inputs from product owner
• First half is spent in identifying stories that are important and the developers are also comfortable with it.
--o During the discussion the following information may be revealed, data sources, interface layouts, response time expectations and considerations for security and usability
--o Team learns what it must build
• In Second half, team determines how it will develop and test those user stories
--o Presence of Product Owner is also required
--o Team determines how it will implement the stories
--o Team attempts to discover whether it can commit to implement all the stories requested by Product Owner?
--o User stories are broken up into tasks
--o Estimation of each task is done in hours
--o A task should not be longer than a day
--o It must be noted that 40% of the work emerges after the sprint meeting
--o Individual estimates of tasks are added to calculate the total time required to complete the user story.
• There may be a situation that duration of task is not clear unless some other task is performed.
Daily Scrum Meeting:
• Objective is to determine what it needs to do in the next day to maximize its chances of meeting its commitments
• Duration should be limited to 15 minutes
• Each member should describe
--o What I have accomplished since most recent scrum
--o What will I accomplish before next scrum
--o What blocking issues or impediments might affect my work

UML Lecture: Methodologies

Source: people.cs.uchicago.edu/~matei/CSPP523/lect4.ppt -

Methodology

“A methodology is a collection of procedures, techniques, tools and documentation aids, supported by a philosophy, which will help the systems developers in their efforts to implement a new information system”

Methodologies are more than a collection of tools and techniques
They specify:
• The stages into which a project should be broken down
• Tasks for each stage
• Outputs produced
• Support tools to use
• How the project is to be managed and controlled
All encompassed in a philosophy

Waterfall Methodology
All phases of SDLC (Software Development Lifecycle) are executed in a sequence. Each phase completes before the next phase starts.
Philosophy of waterfall methodology
The philosophy behind waterfall seem to be that humans can do one thing at a time. Therefore, concentration should be focused on one activity and once it is completed then the other one will start.
The above philosophy is only successful when
• Requirements are known up front before design
• Requirements rarely change
• Users know what they want, and rarely need visualization
• Design can be conducted in a purely abstract space
• The technology will all fit nicely into place when the time comes
• The system is not so complex.

Problems in Waterfall
•Large amount of time and money are expanded before there is any visible results.
•Changes to requirements are difficult to manage and expensive as End-users don’t get to see the product until it is largely complete. At that time they may ask for significant changes.
•Various types of flaws remain undiscovered for lengthy period resulting in large amounts of rework when eventually discovered.

Unified Process or Rational Unified Process
Unified Process uses Unified Modelling Language (UML) although this is not necessary.
Unified Process is distinguished by being
• use-case driven
Project is managed based upon the use cases
• architecture-centric
Focus is on identifying the components and interaction among components
• iterative and incremental
Rather than a Big Bang, project is completed as small increments (which includes use-cases). While completing use cases, certain activities are performed in an iterative way. i.e. Elaboration is performed each time when we move to a new use-case

Phases of Unified Process
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

Inception Phase
• Initial requirements capture
• Cost Benefit Analysis
• Initial Risk Analysis
• Project scope definition
• Defining a candidate architecture
• Initial Use Case Model (10% - 20% complete)

Elaboration Phase
• Requirements Analysis and Capture
– Use Case Analysis
• Use Case (80% written and reviewed by end of phase)
• Scenarios
– Sequence and Collaboration Diagrams
– Class, Activity, Component, State Diagrams
– Detailed understanding and modeling of problem domain.
– Risk Assessment Plan revised
– Architecture Document
Construction Phase
• Focus is on implementation of the design:
– cumulative increase in functionality
– greater depth of implementation (stubs fleshed out)
– greater stability begins to appear
– implement all details, not only those of central architectural value
– analysis continues, but design and coding predominate
Transition Phase
• The transition phase consists of the transfer of the system to the user community
• It includes manufacturing, shipping, installation, training, technical support and maintenance
• Integration with existing systems (legacy, existing versions, etc.)

Wednesday, April 27, 2011

Lecture # 23 Validating Requirements

Lecture # 23 Validating Requirements
It takes 30 minutes to correct a requirement defect in requirement phase
However it may take hours or may be days to correct a defect identified during system testing

A very good practice is to do test planning and create test cases. This reveals defects in requirements early in life cycle.

Validation Attempts to Ensure:
• SRS correctly describes system capabilities
• Requirement are complete and of high quality
• Consistent with each other
• Adequate basis for design and construction

Validation can be done using informal or formal approaches.

Informal approach includes
• Peer Desk check: Ask one colleague to look over your work product
• A passaround: in which you invite several colleagues to examine a deliverable
• A walkthrough: Author describes a deliverable and solicit comments on it

Among Formal Approaches we are going to discuss
• Inspection

Inspection:
• It was first defined by IBM
• Involves small teams of trained participants
• Not specific to requirements but can be used for any software workproduct
• Involves careful examination of work products to discover defects
• A high leverage SQA technique
• It is said that one hour spent in inspection avoids at least 10 hours of labour
• Therefore even being a lengthy task, it should not be avoided
• If there is not enough time, then risk analysis should be done to identify critical requirements and then inspection of those should be performed
• Inspection should not wait for the entire SRS to complete but it should be started as soon as 10% of SRS gets completed.

Participants of Inspection:
Should involve people having different perspectives
Normally four people are involved however the total number of people involved should not exceed 6

People involved can be
• Author or peer of author
• Author of any predecessor work product, e.g. person who document high level requirements
• People who will do work based upon item being inspected
• People who are responsible for work products that interface with items being inspected

Roles involved
Some tasks are delegated to people with in the inspection team
1- Moderator (Inspection leader)
a. Plans inspection with author
b. Coordinates and facilitates activities
c. Distributes the material, days before the meeting
d. Responsible for right focus of meeting
e. Reporting results
f. Follows up with author so that defects and issues raised are addressed
2- Author
a. Much passive role
b. Listens and responds to questions
c. Spotting errors that others don’t see
d. Incorporating the recommendations
3- Reader
a. Reads a requirement at a time
b. Paraphrases, that is explains in his own words
c. Other participants point out defects and issues
4- Recorder (Scribe)
a. Documents issues raised
b. Reads aloud what he has wrote to confirm accuracy

Pre-requisites of Inspection:
Avoids spending time on issues that can be solved before
Moderator should the following before proceeding
1- Document confirms to standard template (If any)
2- Spell checked
3- Layout errors resolved
4- Reference documents required by inspectors are available
5- Line numbers printed
6- Open issues are marked as TBD (To be determined)
7- Moderator did not find 3 major defects in 10 min of time

Inspection Stages
1- Planning
2- Overview Meeting
3- Preparation
4- Inspection Meeting
5- Rework
6- Followup

Monday, April 25, 2011

Lecture # 21 Ways of Developing Prototypes

There are three possible ways of developing prototypes
1. Paper Prototype
a. Cheapest but effective
b. No executable software
c. Paper version needs to be developed
d. Usage scenarios are planned and drawn
e. Analyst may guide the end-user through the drawn scenarios explaining how particular tasks can be completed through the system
2. Wizard of OZ prototype
a. Relatively cheap
b. Usually used when a legacy system is being replaced by a newer one
c. A new user interface is developed
d. The input accepted by interface is then taken up by a person who generates responses, may be after getting them from the old system.
3. Automated/Executable prototype
a. Most expensive
b. Executable product is developed
c. Can be evolved into actual system

Lecture # 20 Prototyping

Prototyping can help elicit and validate requirements
For a prototype, it is necessary that it gets developed quickly, therefore
• Prototypes normally include necessary functions only
• Many management practices and Quality Assurance practices are skipped
• Non functional requirements are ignored
• Sometimes it may be developed using a different technology so that development time is saved.
Benefits of Prototypes
• Allows customer and end-user to experiment thus providing them with an opportunity to refine and improve their requirements.
• Customer can get an idea of how system can be used.
• Suggests overall feasibility and usefulness
• Effective way of developing user interface
• Ensures effective testing
• Since requires careful study thus reveals inconsistencies thus lesser requirement reworks
Problems
• Training is required if the team does not have experience of developing prototypes
• Additional time is required
• May cause delay as development team can get stuck into an infinite loop, where client suggests further improvements and requirements on each delivery of prototype
• Misleading as the emergent behavior may be different from actual product. For example actual payroll calculation for all employees of company may take a lot of time however since the prototype is not considering all records or may be all rules therefore payroll calculation will take less time. The end user may be mislead by this may begin to expect that payroll calculation will always take this much time.
• Can be used majorly for functional requirements
Categories of Prototypes
Throwaway

• Discarded when final system has been developed
• Helps elicit and develop system requirement
• Usually requirements that are hardest to understand are included so that real expectation of client is determined
• Such features are included that are most crucial in terms of difficulties the customer may face while using them.
Evolutionary
• Deliver workable system quickly
• This prototype will be evolved into the actual system rather than developing the system from scratch after refinement of requirement (contrary to Throw-Away prototype).
• Features that are well understood are included
• Features that can deliver useful functionality to end-user are included

Lecture # 19 Activities of Requirement Elicitation

There cannot be a single process of requirement elicitation that can act as a silver bullet. However authors have suggested some activities that must be done while doing requirement engineering
1. Objective Setting:
a. Identifying general goals of business
b. Outline of problem to be solved and need of problem to be solved
c. Identification of constraints including budget, schedule and interoperability
2. Background knowledge Acquisition
a. Acquiring Information regarding the organization
b. Acquiring information regarding application domain
c. Gathering knowledge about existing system that will be replaced
3. Knowledge Organization
a. Organizing large amount of knowledge acquired
b. Involves identifying system stakeholders
c. Prioritizing goals
d. Discarding unnecessary domain knowledge which do not contribute to system requirement
4. Stakeholder requirement collection
a. Involves consulting system stakeholders to discover their requirements
As a result of requirement elicitation a large amount of data is collected. In order to make the data more meaningful, it is important that the organized and structured.

Following are the ways to structure data
1. Partitioning
a. Aggregation relationship. For example in University, a degree is made up of a number of courses. Payroll of a single employee is made up of a number of earnings
2. Abstraction
a. General / Specific Relationship. For example a university offers a Degree which has a number of categories e.g. PH.D., Masters, Bachelors etc. Each category has some special characteristic
3. Projection
a. Organization of knowledge from several different perspectives, For example, information from the perspective of student, details from the perspective of faculty and information with respect to examination etc.

Tuesday, April 12, 2011

UML 3rd & 4th Lecture Scenarios

Use-Case Specification/Description
(Note: Proof Reading will be done soon)

Scenario # 1

Maintenance requests are forwarded by consultant to developer. The developer gives response to request after doing analysis of the request. If the request is something which is doable the developer calculates and gives estimates (Time) to consultant. Incase the request can not be entertained, the developer informs the consultant.
Forwarding request involves recording information about request on an excel sheet and emailing details of request to developer.

Scenario # 2

While issuing admit card the account department checks fee payment and checks attendance. If the fees is paid and attendance is complete then admit card will be issued. If fees is not paid then student has to submit an undertaking identifying the date by which fees will be submitted after which admit card will be issued. Incase student is short of attendance the account department may ask for medical certificate to know the reason of absence. If the reason is not valid the admit card will not be issued.

Scenario # 3

An associate can add information regarding contacts. He can also update the status of contact to a prospect or client. When the status of contact is updated it is shifted from public list to private list of associates. If the contact was already in communication with other associates then an email will be sent to all the other associates in order to inform that they can no longer do business with contact.

Scenario # 4

On receiving an order the salesman packages the goods and creates a bill. If it is found that the items are not available in the shop then they are brought from warehouse before creating package. In addition, if after creating package of goods it is found that specific goods are not left in shop then they are brought from warehouse.






Activity Diagram

Scenario # 1

While processing an order a salesman determines price of individual items and calculates the total amount of bill. If the amount of bill exceeds 5000 then a discount of 10% is offered. Salesman also checks if the customers process a “Valued Customer Card”. If the customer is valued customer then 10% discount is offered.

Scenario # 2

Employee submit leave application manager approves leave application and forwards it to HR department which performs deductions of leaves.

UML Lecture# 2 Use Case Diagrams

A Use Case diagram models the functionality of the system as perceived by outside users, called actors. • Use case diagrams – Highlight the functional requirements of the system i.e. what the system should do – Since it records “what the system should do”, thus it become the basis for performing tests that verify whether the system doing what the user expects – Pthe ability to trace functional requirements into classes and operations • Audience of Use Case diagram – Clients can see the use case diagram to confirm whether the system will do what they expect – Quality Assurance Team may refer to use case diagrams while verifying whether system meets the expectations of clients – Architects may use the diagram to see what functionality should be made available to various users Components of a use-case diagram • Use-cases – Represents a complete functionality as perceived by an actor – It encapsulates a description of a set of sequence of actions, including variants that the system performs to yield an observable value to an actor. The sequence and variants are documented in a use case specification • Actor – representing a role that someone might play, rather than a particular individual – external entity that has interest in interacting with the system – Someone who gives input or receive any output from the system • Interaction – a communication relation between an actor and a use case Drawing a use case diagram • The first step is to identify the actors • Then we should identify the activities that are initiated by actor or the activities whose output is received by an actor. • It should be seen whether any sub activities are performed or whether some actions are performed in special situations Use Case Relationships A use case is usually associated with an actor. This association is known as communications associations The navigation direction of an association represents who is initiating the communication Relationships also exist between use cases Generalization relationship: Sometimes certain use case is a specialized version of another use case. For example, Conduncting a Test is a general situation whereas a Conducting a Mid-Term is a special situation that has all the processes/steps of Test as well as some additional steps/ Include – Base use case explicitly incorporates the behavior of another use case – It enables us to avoid describing the same flow of events several time by putting the common behavior in a use case of its own • Extend – An extend relationship between use cases means that behavior of another use case is conditionally incorporated in the base use case – Use an extend relationship to model the part of a use case the user may see as optional system behavior

Monday, April 4, 2011

Lecture # 18 Problems in Each Dimension

Objective -Understand problem in each dimension Introduction While gathering information from various dimensions, a number of problems are faced. Following section enlists the problems under relevant headings Problems in Application Domain • Knowledge is scattered in books, brains and manuals • Problems are also faced while referring to these sources because the presence and usage of specialist terminologies. For example, while making a system for managing financial products a developer may encounter terms like Premium, On Risk Date, Income Protection etc. In order to better understand documents etc. such terms may first be understood. Problems in Problem Analysis People who understand the problem are sometimes so busy or they have some deadlines to meet because of which they have less priority for sharing information with requirement engineer In some situations, they may not be convinced that the system is necessary/useful, therefore they resist its development by avoiding sharing information or in some cases correct information Problems in Business Understanding: • Higher management may try to present requirements in such a way that they gain more control. They initially decided and main objectives may be different but higher management may latter realize that there is an opportunity of getting other advantages from the system. Thus they will try to include additional requirements that may to contribute in achieving the actual objectives of the system. Problems in Understanding Stakeholder Constraints and Needs: • It is a common observation that stakeholders don’t really know what they want or in some cases they find it difficult to articulate their needs and wants. • It has also been observed that they have unrealistic demands because they are not aware of the technology constraints. For example the client may demand a mobile application that allows users dictate SMS. This application is technically impossible with the current technology. • One other issue is that same requirement is expressed differently by various stakeholders belonging to various levels of organization. Other problems • Economic and business environment changes, this may affect the importance certain requirements or even certain applications. To understand this, let’s discuss an example out of the IT domain. A recording company decided that it would make cassettes by itself and it started working on this project. While they were in the initial stages of this project, CDs came into the market and soon it became clear that CDs will replace cassettes. The business will now lose its interest in the project related to cassettes as it will not be worth spending money on it. • Requirements from new stakeholders who were not originally consulted • People who were consulted initially changed their jobs • Stakeholders forget what they said. For example, one of our clients indicated that some fields must have defaulted to commonly used values so that users don’t have to type everything. However at a later stage of project they complained (forgetting that it was their own demand) that because of the default values end-users do not fill the complete form and they leave the default values as they are.

Saturday, March 26, 2011

Lecture # 2: Scenarios for practising Use Case Diagram

Scenario # 1

A patient takes appointment with scheduler for checkup. On the appointment date the doctor performs checkup. While doing checkup the doctor checks body temperature and blood pressure. In addition, the doctor also looks at the previous medical record, if it is available in the clinic. Finally, the patient pays fee to doctor.



Scenario # 2

An employee can apply for leave. For applying, an employee will have to submit a form. In case of annual leave a manager will have to approve leave. While approving, the manager will confirm that employee has sufficient leave balance and no critical task are assigned to him.


Scenario # 3

End user submits their registration form. The details of the information are compared by administration with existing data. If the information is verified then the End user is activated. Activation involves sending Emails, containing username and temporary password.

Wednesday, March 23, 2011

Lecture # 17 Requirement Elicitation

Requirement Elicitation
Objectives
• Understand Requirement Elicitation
• Understand information that should be gathered in Requirement Elicitation
What is Requirement Elicitation?
It is the name given to activities involved in discovering requirements of the system
It involves learning about the problem to be solved through brainstorming and questioning. It involves identifying who the actual users are, what are their needs and what constraints. Dimensions of Information Gathered in Elicitation
The information that combines to form the requirements of the system have at least four dimensions and requirement engineer must gain understanding of them
These include
1. Understanding Application domain
2. Understanding The Problem
3. Understanding The Business
4. Understanding The needs and constraints of stakeholders
Understanding Application Domain:
This involves gaining general knowledge about the application domain. For example, when you are making a sales system for an Asset Management Firm you must have a general idea of what is asset management and how various products are sold.
Problem Understanding
The general concepts and ideas gained should be specialized and the details of specific customer problem where the system is going to be applied must be understood. For example after having an idea of how financial products are generally sold, you must extend the knowledge by gaining information about how the company for which you are developing solution sells the products
Business Understanding
This involves gaining knowledge of organization’s goals and how the system will contribute to the achievement of goals. It also involves studying and understanding the environment in which the system will function in order to identify the other systems with which a system will interact. Let’s take the example of asset management firm again. A requirement engineer must have gain information about the sales system will contribute towards the achievement of organizational goals. The goal of a company may be to increase sales by providing sales team with more and more time to spend with customer. In addition, the company has its own email server through which sales team send follow up emails to customers. These two items will influence the solution that will be proposed and if these are overlooked then the final output may not be very useful/satisfactory for the client
Understanding the needs and constraints of stakeholders
Finally, it is very important to take detailed information from stakeholder regarding their actual needs and their expectation about how the system will support their work. It also involves getting details of processes they perform and how they use the existing systems use to perform those processes.

Lecture#1 Introducing Modeling and Unified Modeling Language

Objectives:

  • To understand what is Modeling and why it is important
  • To know what is UML?
  • To understand the purpose of Use Case Model
    Model:
    Model is a simplification of reality
    Example: When you go to buy a bungalow, you are shown a model bungalow and/or a plan (layout) of rooms etc. These are examples of model through which you are given an idea of how the model bungalow will look like and whether it meets your requirement or not.
    Modeling:
    The process of developing models is known as modeling
    Why we Model ?
    Modeling is done so that we can comprehend complex system and we can focus on particular aspects of the system
    Modeling Language:
    A modeling language provides notation as well as guidance regarding how these notations can be used to exhibit various aspects of the system. Using these notations and recommendations people can model useful views of the system
    Points to Remember
    • A single model can never be sufficient for a system that is not simple. For example when we go to purchase a house in a housing scheme that is about to be constructed, we are shown the floor plans of house so that we are informed about various aspects of house that we can understand. The floor plan includes information about the number of rooms, their arrangement, size, position of windows.
    However that’s not the only diagram/plan created. There are other plan/diagrams which explain the position of beams and columns (pillar) whose audience is the contractor. There may be other diagrams that explain the layout of electric and plumbing lines
    • Models should be drawn with different levels of precision, i.e. An initial model may explain the high level details where as a detailed version may be available for identifying low level details.
    For example an international bank may have a diagram that highlights the countries in which its branches are present. As the next level of detail, the bank may have diagrams for individual countries that highlight the cities of a particular country in which the branches are present. Finally, another level of detail may include a diagram that identifies the areas of a particular city in which branches
    • If the modeling is done properly and carefully then there are high chances that the system will be developed
    Importance of Standardized Modeling Language
    The importance of modeling was strongly felt by the industry when software solutions started becoming complex. Complexity of software required them to be modeled properly and in addition to this the development of software began to involve a number of roles. Thus the need for effective communication between these roles arose.
    Initially these needs were fulfilled by modeling languages that were not standardized i.e. Every vendor used a different set of notations to model artifacts of software. The problem in this approach was that the artifacts were not understandable by everyone and people outside the vendor organization found it very difficult to understand those models properly
    Unified Modeling Language
    UML is a language for visualizing, specifying, constructing and documenting the artifacts of a software intensive system.
    It is called unified, because three writers Booch, Rumbaugh and Jacobsons and countless other in the OO industry have created Unified Modeling language by merging all previous work and standardized to be accepted by everyone.
    UML Diagrams
    Structural Diagrams
    • Class Diagram
    • Use Case Diagram
    • Component Diagram
    • Deployment Diagram
    • Package Diagram
    Dynamic Diagrams
    • State
    • Activity
    • Interaction
    o Sequence
    o Collaboration

Saturday, March 12, 2011

Lecture 16: Process Improvement and Process Maturity

Objectives:• Understand what is process improvement?
• Learn how it should be carried out

Process Improvement Process Improvement came to prominence with the notion of business process engineering. It involves rethinking redesigning current process to be more efficient and effective
Proper planning and investment of time and resources is required for process improvement
Planning Process Improvement
Four Questions need to be asked
1. What are the problems in Current Process?
a. There may be identifiable problems like
i. Late Delivery
ii. Poor Quality
iii. Poor Quality
b. You need to know
i. What are the current processes
ii. How much they are followed
2. What are the improvement goals?
a. The above activities would have highlighted a number of problems. This step involves identifying or selecting any of the problems for improvement that were identified in the previous phase
3. How can we introduce process improvement?
a. Identify processes that cause most problems
b. What changes can be made to them?
c. Remember that sudden changes must always be avoided
4. How should improvement be controlled and managed?
a. Procedures to collect feedback must be determined so that it can be judged whether the improvement is beneficial or not?
b. Actions should be taken in response to feedback.
Process Maturity: It is the extent to which the processes are defined and controlled.
SEI’s Capability maturity model (C.M.M) is a framework for assessing software process maturity in development organization
C.M.M defines a framework consisting of three levels
Level 1 (Initial): Organizations have undisciplined processes and it is left to individuals to decide how to do things
Level 2 (Repeatable): Have basic cost and schedule management procedures
Level 3(Defined): Project management activities and engineering activities standardized
Level 4(Managed): Detailed measurement related to process and product are collected and used to control processes
Level 5(Optimized): Have continuous process improvement strategy based on strategic measurement in place

Thursday, March 10, 2011

Rare Http Errors

As software developers you may encounter following errors. I my self encountered them and had to research a bit to find the reasons and solutions. Following are the errors and corresponding solutions

HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list

The solution for this problem is available in the following web URLs
http://forums.asp.net/t/1480233.aspx
http://forums.iis.net/p/1149449/1869918.aspx
I was facing this problem because ASP.NET was not registered properly. This often happens when you remove and add the IIS component again or you installed IIS after .NET. Executing the following helped me.
%windir%\Microsoft.NET\Framework\v4.0.21006\aspnet_regiis.exe -i

HTTP Error 404.17 - Not Found - The requested content appears to be script and will not be served by the static file handler
The solution for this problem is available in the following web URLs. It normally occurs when you have not selected the right pool for your application. Application pools can be changed from advanced settings in IIS 7
http://www.gtrifonov.com/blog/2009/02/27/IIS_7_HTTP_Error_404_17_The_requested_content_appe.aspx
HTTP Error 404.2 - Not Found
The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.

This occurs due to the reason thatISAP or CGI resources are not allowed on the server. Following URL provides the solution in detail.
http://support.microsoft.com/kb/942040

Lecture 15: Human, Social, Organizational Factors and Process Improvement

Objectives:
Identify human, social and organizational factors involved in R.E process
Suggest the remedies and mitigates
Introduce Case tools and Process Improvement as a way to improve R.E

Human, Social and Organizational Factors
• Stakeholders come from various backgrounds thus they use different terminologies. It may be possible that the same concept or situation may be explained in different terminologies by different level of Stakeholder
Solution: Requirement Engineers are able to overcome this situation if they have experience of working for the particular domain. E.g. if a Requirement Engineer has analyzed banking environment and operations that he will be in better position to understand the lingo used by stakeholders. Therefore, it is necessary that some domain knowledge is obtained before starting the requirement engineering process
• People often have their personal responsibilities and have specific deadlines to meet. Therefore, they might give less priority to help requirement engineer in gathering requirements. They may also avoid contact or shorten the communication as much as possible.
Solution: First thing is to have some knowledge of the domain. Secondly some preparation and planning should be done to determine the availability of people to be interviewed. Where necessary alternative measures of gathering requirements like questionnaires should also be considered. Keeping higher management of client organization in the loop by informing them about the commitments and appointments of the employees also helps a lot because this somewhat pressurizes them fulfill the commitments and make themselves available at the appointment time.
• Stake holders have some internal differences or grudges and they try to provide requirements accordingly. For example, one group of people may try to provide a set of requirements that will give them more control of certain resources than the opposing group. Another situation may that a group or individual will attempt to provide requirements in such a way that the system fails as the supporter of system is a rival.
• Stakeholders provide requirements in such a way that their individual needs and wants are fulfilled rather than those of the organizations
Solution of the above two: The solution to the above two is Domain Knowledge. This knowledge will help user in differentiating the actual requirements of the system from those that may not be requirements of the system
In addition an unfortunate situation is that sometimes we as requirement engineers have to accept wants and needs of individuals because of their political influence in organization. It may also happen because the individual/group is the one because of whom we have got the contract and he may also play a role in cancelling it.

Various problems in Requirement Engineering process can be avoided or we can overcome them by
• Using CASE Tools (Computer Aided Software Engineering): These are automated tools that are used to manage various of Software Engineering Process
• Process Improvement: We can improve the way we do software requirement engineering by either gradually improving are activities or by planning and implementing big changes in the process.

Wednesday, February 16, 2011

Lecture 7 and 9: Domain Requirements, Inverse Requirements, Perspectives of Requirements

Lecture 7
Domain and Inverse Requirement
Objective:
Provide explanations and examples to make student understand what domain requirements are?
To know what inverse requirements are?
Examples as a Food For Thought
-The hospital management system should support the check-in and check out for IPD (In Patient) and oPD Out patient Department
- The GL system should have the ability to post Double entries
- The GL system should have the provision of maintaining chart of accounts
- System will keep claim records & losses reserves, Financial Transactions and Claim expense records
- Supporting associate agents at the policy level setup commission due based on written premium, on invoicing or on premium payments and generating agent statements
Carefully go through the above examples and you will find terms that you won’t understand. This highlight two important aspects
1. People belonging to the field of software engineering must know about other domains
2. Some of the requirements may not be mentioned or explained explicitly because the people belonging to that domain may consider them implicit or understood.
Such requirements are considered as domain requirements. Following are some characteristics of domain requirements
1. They may be functional or non functional
2. Reflect the characteristics and come from domain
3. Sometimes not explicitly mentioned
4. Absence of these can cause significant dissatisfaction
5. Sometimes pose strict constraint on system.
Inverse Requirements
• Inverse requirements can be functional and non functional
• When a customer specifies that something must not be done. For example, User ID should only contain digits.

Lecture 9
User and System's View of Requirement
Objectives
• To understand what User/ Customer’s View of requirement should represent
• To Understand what System and Contract view of requirement should contain
What user’s/customer’s view of requirement should contain?
• Should include a description of user’s need, functional and non functional requirements, expectations and constraints
• Explained at a higher level of detail
• Specified inform of natural language
• May include diagrams which mostly are drawn in such a way that there is no need to learn any modeling language to understand them.
• Should not include technical terminologies of Computer Science/ IT domain incase, especially incase where readers are not IT literate
• Detailed discussion on system requirements should not be included
• Design aspects should not be included at all.
What System’s/Contract view of requirements should contain?
• Functionalities, services and constraints explained in detail
• Technical details included
• This must be complete and consistent because incompleteness may lead to failure
• Used by designers and developers as a starting point for design etc.
• Should be understood by customer and development team, especially if they are IT literate.
• Used to develop initial architecture
• Documented in natural language and may contain diagrams developed in modeling language like UML.
• May contain information regarding architecture in two situations
o The client has specified some design and implementation constraints
o There is some interoperability with an existing system and some architectural constraints due to that will be included
Some Concerns Regarding Requirements
• Very expensive to change after they have been finalized
• Sometime requirements are not clear because the human languages lack clarity
• Sometimes team is not sure about the category in which a requirement falls.
• Sometimes requirement amalgamation is faced where a number of requirements are specified in single line.
• A single line can be perceived differently by readers
• A single line can be phrased differently

Monday, January 31, 2011

Lecture 5 & 6: Case Study and Metrics for Nonfunctional Requirements

Objective:
Highlight the importance of converting NFR into quantifiable form
Provide examples of Metrics which be used to quantify requirements or to derive customized metrics.

Goals and Nonfunctional Requirement
Non-functional requirements are sometimes written as general goals, which are difficult to verify. They should be expressed quantitatively using metrics (measures) that can be objectively tested

• Goal (unverifiable)
– The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

• Non-functional requirement (verifiable)
– Experienced controllers shall be able to use all the system functions after a total of two hours’ training. After this training, the average number of errors made by experienced users shall not exceed two per day

With the help of following metrics the NFRs can be verified quantitatively. It should also be noted that the cost of quantitatively verifying each NFR may be very high

It must also be kept in mind that there may be other metrics for various non functional requirements and the following list just provides you some examples so that you are able to understand that how various NFRs can be made quantifiable.

Metrics for Non-Functional Requirements
Before moving ahead it is important that we understand the difference between terms, measure, measurement and metrics
Measure refers to an individual value where as Measurement refers to the process of calculating the value i.e. Measure. Metrics relate measures so that some conclusion or decision is made. For example there are two measures, LOC(Line of Code) and Total errors. If we combine these two (Total Errors/Kilo Loc) then we may be able to judge the skills of development team.

Speed
• Processed transactions/second (For Transaction Oriented Systems, e.g. POS Systems)
• Response time (Can be used for systems that perform very lengthy and complex tasks. For example a software to recover contents of hard drive )
• Screen refresh time. (For games)

Ease of use
1. Training time
2. Number of help frames

Reliability
1. Mean time to failure (For non repairable systems)
2. Mean time between failure (For repairable systems)
3. Probability of unavailability
4. Rate of failure occurrence
5. Availability

Robustness
It is the capability of system to function correctly in unexpected or abnormal situations
1. Time to restart after failure
2. Percentage of events causing failure
3. Probability of data corruption on failure

Portability
1. Percentage of target-dependent statements
2. Number of target systems

Reference: Lecture # 3 By Dr. Ghulam Ahmed Farrukh, Virtual University Pakistan

Monday, January 24, 2011

Lecture # 4: Kinds of Nonfunctional Requirements

Objective:
This lecture identifies and elaborates the various kinds of Nonfunctional requirements

Nonfunctional Requirement
Following are the types of nonfunctional requirements.
• Product Requirement
o Usability Requirement
o Efficiency Requirement
 Performance Requirement
 Space Requirements
o Reliability Requirement
o Space Requirement
• Organizational Requirement
o Standard Requirement
o Implementation Requirement
o Delivery Requirement
• External Requirement
o Interoperability Requirement
o Ethical Requirement
o Legislative Requirement
 Privacy Requirement
 Space Requirement

Product Requirement:
Product requirements refer to the output of the entire project and project management initiative. This output is called product and product requirements refer to the quality attributes of this output. Product Requirements are further subcategorized into.
• Usability Requirement
These refer to the requirement related to user interface. For example,
“The user should have the facility to dial numbers either by selecting name from contact list or by speaking out the name”

• Efficiency Requirement
These are further divided into
o Performance Requirement
Such requirements refer to the speed of processing user requests, For example
The system should allow 100,000 hits per minute on the website
o Space Requirement
Such requirements refer to the space constraints. For example,
The version of application running on handheld device should not consume more than 1 MB of working memory.
The website will be hosted on an external server. The external server allocates 300 MB of space to each website

• Reliability Requirement
Reliability refers to probability that, a software will provide failure free operation in a fixed environment for a fixed interval of time. Example,
The system should not have a downtime of more than one second for continuous execution of 1000 hours.

• Portability Requirement
Portability refers to the capability of system to perform its functions on multiple platforms or environments. Following is an example of portability requirement
The system should run on both Microsoft and Linux platforms
The web site should be accessible from latest version of Internet Explorer, Chrome, Firefox and Opera.

Organizational Requirement:
There are certain requirements which are not related to the output or product, but are related to the processes and various options that are available to team during development. These options may be specific methodologies and standards that should be followed by the development team while developing the project, or technologies and techniques that can be used to develop and deliver project.
The term organization refers to both developer organization and client organization. Sometimes clients may ask the usage of specific technology for example, whereas sometimes the development team uses certain technology or standard, due to policy or expertise of developer organization
• Standard Requirement
These refer to any constraint to use certain standards. For example,
All development work subcontracted by the development organization shall be carried out in accordance with CMMI
• Implementation Requirements
These refer to the constraint related to implementation aspects which may be usage of specific technology (e.g. .NET), design pattern (e.g. MVC) or paradigm (e.g. O.O.P)
• Delivery Requirement
These refer to the constraint on how product will be delivered. For example,
On Completion, the website should be copied to local server using FTP.
The website and all dependencies should be provided in a DVD.

External Requirement:
Any other authority or stakeholder that is not part of development or client organization lies in the “external” category. In addition, the systems with which the product will interact also lie in the “external’ category. Requirements that come from such external entities are known as external requirement.
Interoperability Requirement:
Any information that identifies the systems with which the product should interact is an interoperability requirement. For example,
The system should send notifications which should be viewable by existing lotus notes applications.
The system should record task information and should also post it on Google calendar.
Ethical Requirement:
There are certain ethics that should be followed by developers and product which are referred to as ethical requirements
Legislative Requirement:
With the popularity and wide usage if IT, legislations have been made regarding usage/implementation of IT and regulatory bodies ensure that the law is followed properly. Any requirement to follow certain law comes in legislative requirement
Legislative requirement can be
• Privacy Requirement
There may be legislation about how securely data should be stored in the system. Specially in a banking sector such constraints are present and are specified by the central bank of the country.
• Safety Requirement
Software systems are now used in scenarios where safety is a major concern. Malfunctioning of software system will put lives of humans on risk. Therefore certain standards have been developed which ensure that the software is reliable enough to be used in such scenarios. Regulatory bodies may make it mandatory for software to follow a specific safety standard.

Sunday, January 23, 2011

Lecture # 3: Exercises to Clarify Concepts

Objectives:
• To further clarify the difference between non-functional and functional requirements using examples
• To develop, using examples, a sense to identify incompleteness of requirements.

Exercise 1:
Identify how the following requirements are incomplete

1. An email notification must be sent to user when he successfully registers into the system
2. The system will allow salesman to maintain their personal contact manager. When a contact is converted into client then other salesman having duplicate of these contacts in their personal contact manager are informed that they cannot do business with this contact.
3. The installer should check the prerequisites before starting itself.

The missing aspect in “1” is that it is not clear that what will be the contents of “email notification” sent to client

There are a number of missing aspects in “2”. It is not clear that how the other sales man will be informed that contact has been converted into business. Secondly, it is also not clear on what basis duplicates will be detected. (There may be more incomplete areas in “2”).

In “3”, the requirement engineer should inquire about the prerequisites that should be checked by installer.

Exercise 2:

Identify functional and nonfunctional requirements from the following

1. The system should have a very easy and intuitive view of customer transactions
• Functional Requirement: View of customer transactions
• Nonfunctional Requirement: Easy and intuitive

2. Authorized users should be able to modify customer’s personal information
• Functional Requirement: Modify Personal Info
• Nonfunctional Requirement: Authorization or Security

3. The system should calculate monthly summary of inventory and send email using mail server’s contact list.
• Functional Requirement: Calculate monthly inventory summary and send mail server’s contact list.
• Nonfunctional Requirement: Interoperability with email server such that contact list is accessed

4. The system should allow users to customize workflows. All system development should be done using scrum methodology
• Functional Requirement: Customize workflows
• Nonfunctional Requirement: All development will be based on scrum methodology.

Monday, January 17, 2011

Requirement Engineering: Lecture # 2

Objectives:
To develop skills to identify stakeholders of software
To learn various kinds of requirements
To have clear concepts of what functional requirement is?
To have clear concepts of what Nonfunctional requirements are?

Exercise: Identifying Stakeholders
It is really important that you get requirements from all stakeholders because the system may fail because a stakeholder is not satisfied or he had some important requirements with him, which did not get captured and thus not implemented. Following exercises are there to bring you in a habit of deep thinking to identify stakeholders.
• I want to take all quizzes using a software. Who will be the stakeholders in this scenario?
Answer:
Stakeholders may include at least the following
• Students
• Teachers
• Academics/Management
• Lab Administrator

• I want to develop a software for automating traffic signals on the road
Answer:
Stakeholders may include at least the following
• Police
• Drivers
• Pedestrians
Ambulance and other emergency transport including VIP squads

• I want to develop a software for automating the railway signals
Stakeholders may include at least the following
• Train staff/operators
• Car drivers

Lecture Contents:

Kinds of software requirements
• Functional Requirements
• Non Functional Requirements
• Domain Requirements
• Inverse Requirements
• Design and Implementation Constraints

Functional Requirement
These are statements that describe what the system does. In other words these are the statement of services the system should provide. They identify
• Reaction to particular input
• Behavior in particular situation
Sequencing and parallelism should also be captured by functional requirement as well as the abnormal behavior, which is documented in the form of exception handling.
E.g. The system should allow user to search for books, CDs and journals available in library
E.g. The system should record basic information regarding all the financial products as well as basic information about the provider and product related documents including brochures and forms
While documenting any kind of requirement, it must be ensured that complete requirement is being captured so the chances of misinterpretation or different interpretation is minimized
Customers and developers usually focus all their attention on functional requirements

Non-Functional Requirement:
These do not deal with the actions system do, but they rather they deal with the quality attributes of the system. They contribute to the emergent behavior of the system.
Non functional requirements are often neglected by the developers and requirement engineers. However they should be given due share specially due to two important reasons
Like some functional requirements, Non functional requirements are so important that there absence will effect acceptance of the product by client. For example,
• A Point of Sale terminal at super store should allow operators to quickly generate receipts for customers. If it takes long the management might discard it.
• A system like ZABDESK may be discarded by management simply because it not secure enough and someone can breach in to change the marks

It is important to know the Nonfunctional requirement at a very early stage because these requirements are built into the architecture of the system. Almost all functional requirements can be added after the delivery as well but most of the Nonfunctional requirements cannot be added later. For example, high performance can only be achieved if the architecture is aimed at it, it cannot be added later.

Tuesday, January 4, 2011

Requirements Engineering Lecture # 1: Introduction To Software Requirement Engineering

Learning objective
• To know what actually a requirement is?
Learning outcomes
• Detailed knowledge of what requirement is?
• Information of what is not considered part of requirement?
• What are the sources of requirement?
Overview
All softwares are made considering some requirements thus requirements form the foundation of the entire software process. Obviously, if the foundation of certain initiative is not correct then the entire initiative will end up as a failure
Why should we give importance to requirements?
As already mentioned, Requirements are the foundation of any software development initiative and if the requirements are incorrect the entire initiative will possibly lead to a failure.
To understand the importance further, let’s revisit a brief definition of a quality software

Quality software is one that meets the requirements of its end-users

No matter how innovative solution you give to user at lowest price and with promising service, the user will never be satisfied unless his/her requirement is not met

Let’s say, I ordered my tailor to stitch a suit that I can casually wear. I had limited budget and I could afford a single such suit at the moment. But my tailor within the same time frame and cost stitched a suit that was of supreme quality and design such that it was only suitable for very, very special occasions. In such scenario, I, as a customer will never be satisfied as my need did not get fulfilled and I no longer have any resources to acquire a dress that fulfills my need. Thus, the suit stitched by tailor, even after being the best of its kind, was least useful to me.
Therefore it is important that the requirement are correctly obtained and met so that the output satisfies the customer.
What is Engineering?
It is the practical application of scientific knowledge in the design, building and control of machines, roads, bridges etc.
To understand engineering further, lets read the definition of software engineering
The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software
When is engineering done?
Think for a moment, there are a lot of houses in villages or poor localities. Small bridges for pedestrians are also built in villages. But does their development require services of engineer who apply scientific knowledge or who follow systematic, disciplined or quantifiable approach?
The answer is obviously No.
It must be noticed that the above mentioned structures are there to fulfill very simple and primitive needs, however as the needs becomes complex the need of engineering i.e. application of scientific knowledge and adoption of systematic, disciplined and quantifiable approach arises.
Therefore, it must be remembered that as the needs become complex, the need for formal engineering increases.
Requirement Engineering:
When the scientific knowledge is applied or a systematic, disciplined and quantifiable approach to gathering, managing and documenting requirement is adopted, then it is known as requirement engineering
What is Requirement?

Definition 1: It is something wanted or needed.
Requirement Engineers must understand the difference between need and want. And they should have the required knowledge and skills to make customers understand what are their actual needs are

Definition 2: Complete description of what the system does rather than how
It is important to note that requirements must contain what i.e. the real objectives that must be achieved. The detailed design and procedures that must be followed to achieve the objectives are out of the scope of requirement engineers.
But it must be remembered that end users feel more comfortable in explain how rather than what.

Definition 3: It describes the complete specification of desired external behaviors of software system to be built
Complete specification means what system does from the perspective of different stakeholders
External behavior is the outputs that users get after giving certain inputs. It must be remembered that users judge the system based upon the external behavior.

Definition 4: A Condition or capability that must be met or processed by a system to satisfy a contract, standard, specification or other formally imposed document
Condition can also be considered as a constraint and capability is better known as functionality by many
Sources of Requirements
• Stakeholders (Entities that are interested in or are affected by the system)
• Documents
• Existing System
• Domain-Business Area

Lecture 2 & 3: Basic Windows Application using Visual Basic in Visual Studio

Note: Uploading screenshots is taking time... I will upload soon
Learning Objectives:
• To understand the basics of Visual Basic Language
• To develop simple windows based application through visual studio
Learning outcomes
• Understanding of multi-language support in .Net
• Understanding of syntax of visual basic
• Familiarity with the environment of Visual Studio
Multi-Language Support:
As mentioned in previous lecture that the compiler of every language in .NET generates the same MSIL code. This also leads to language independence, as any compiled code is in the common format thus understandable by compilers of other languages (within) as well.
In addition it must be recalled that the assembly executed by CLR also contains MSIL which implies that CLR is not concerned or aware of the actual language in which code was written and treats the compiled code of all languages in the same way
Integrated Development Environment:
An Integrated Development Environment (IDE) brings all of the programmers tool’s into one convenient place. There was a time when programmers had to edit files, save the files out, run the compiler, then the linker, build the application then run it through a debugger.
Today's IDEs bring editor, compiler, linker and debugger into one place along with project management tools to increase programmer productivity.
Visual Studio
Visual Studio is an IDE for building ASP.NET Web applications, XML Web Services, desktop applications, and mobile applications. Visual Basic, Visual C++, Visual C#, and Visual J# all use the same integrated development environment (IDE), which allows them to share tools and facilitates in the creation of mixed-language solutions

For creating new projects navigate to the menu and on clicking the New Project option following screen will be displayed from which you will have to select the project type and language. The figure 2.1 shows selection of “windows application” using Visual Basic language. After choosing the appropriate template i.e. “Windows Application” give a name to the project which will be store by default in Documents if Express edition of visual studio is used.


Fig 2.1

Once you create the application a screen similar to the following will be created.


Fig 2.2

As can be observed that the IDE consists of a number of menus and windows. Let’s see the purpose of each window that can be seen on the screen. On the top left is the solution explorer. Figure 2.4 focuses on solution explorer only.



Fig 2.3

Solution Explorer allows you to view items and perform item management tasks in a solution or a project. It also allows you to use the Visual Studio editors to work on files outside the context of a solution or project. A single solution and its projects appear in a hierarchical display of solution explorer that provides updated information about the status of your solution, projects, and items. This allows you to work on several projects at the same time. Because the selected project and item determines the toolbar icons, this list is a partial representation of those you might encounter while working in Solution Explorer.

(Icon Image will come here)Displays the appropriate property user interface for the selected item in the tree view.
(Icon Image)Shows all project items, including those that have been excluded and those that are normally hidden.
(Icon Image)Refreshes the state of the items in the selected project or solution.
(Icon Image)Launches Class Designer to display a diagram of the classes in the current project. (Icon Image)Opens the selected file for editing in the Code Editor.
(Icon Image)Opens the selected file for editing in the designer mode of the Code Editor.
(Icon Image)Adds a Solution Folder to the selected item. You can add a Solution Folder to the solution or to an existing Solution Folder.

Apart from solution explores you can also see a properties window and a toolbox shown in the figure that are following.

Fig 2.4


Fig 2.5

The details of the above mentioned windows will be discussed later.

In figure 2.2 you must have observed the following at the center. This is the designer of form.


Fig 2.6

Before continuing the discussion lets first see what is a Windows Form.

Windows Forms: are the base unit of your windows application. It is actually a blank slate that you, as a developer, enhance with controls to create a user interface and with code to manipulate data. Controls are actually graphical user interface components through which end-users communicate with your application. Visual Studio displays the set of controls that can be used by the programmer in toolbox (displayed on figure 2.4).
Recall the definition of software frameworks that they consist of collection of items and plug-in points where users can insert instructions/code. The controls are basically the items that programmers can use to quickly develop graphical user interface and you can also associate code/instructions with each control. These instructions get executed when the end-user interact with the user-interface. For example, you may want a message box to be displayed to the user when the user clicks a button (control) on the form

Developing the First Application:

Let’s create a simple application consisting of a button which when clicked will display a message box consisting of message “Hello World”. The learning outcome of this will be that you will learn how to add controls to form, associate code with the control and execute the code. In addition the objective is to also let you know about the structure of instruction and the basics of the grammar of C# technically known as syntax.
To develop the application, open a new project. (Read the beginning of notes for lecture # 2). The designer (refer to Fig 2.6) will be displayed at the center, on the left solution explorer (Fig 2.3) and properties window (Fig 2.5) will be displayed. On the right side toolbar will be displayed (Fig. 2.4). Click “Button” on toolbar and then click on the form being displayed on the designer. This will cause a new button to be created. Congratulations you have created your first object belonging to the category/class Button. As discussed that each class/category has certain characteristics (data/methods) that all the objects possess. If you want to see the data associated with the newly created button object. Right-click the button and click properties from the menu displayed. Observe that the properties window will become activated. The properties window consist of data associated with the object and the values stored in each data field. If you want to modify the data you can simply change the value.
Lets change the “Text” displayed on the new button object. For that go to the text property in the property window and type “Click Me”. (You can enter any message of your choice).
In order to associate code with the button, double click the button and you will go into the code view. The code view allows you to write instructions or in other words do the programming for the form. Type the following line at the location where cursor is blinking.

After writing this line, go to the debug menu and click start debugging. This will cause your application to execute.

Adding More Controls:

Let’s add another control which is known as TextBox. Again follow the same procedure i.e. click TextBox on the toolbox and click on the form. This will create a text box. The textbox also consists of a property known as Text. Whatever is written in the text property will be displayed in textbox.

The next task is to display the contents of the TextBox in the MessageBox when the button is clicked. As mentioned that text property stores the contents of the textbox, therefore in order to get the contents of the textbox, we will write the following instruction

In order to display the contents in the message box we will modify the above code as follows.


The above line states that the contents of textBox1.Text should be given to MsgBox which, as we have already seen, will display whatever that has been passed in brackets.
Label Control:
Currently the form does not contain any indication about what should be entered in the textbox. For such a purpose, Label control is used and the process of adding it is same. As in other controls studied so far “Text” property here is also used for indicating what should be displayed in the Label
String constant:
When you observe the above codes regarding message box you will identify that when displaying a predetermined set of characters (also known as String) in the message box, we used double quotes (“”). However when we wanted the contents of textbox which obviously depends upon the input of the user, we didn’t use the double quotes. Actually when any thing is written outside double quote it is considered to be something that the compiler/runtime should evaluate however things that are written in double quotes are considered as string constants
Variables:
Variables are place holders that can hold data values. For example age can be stored in a variable for further processing. Similarly Text property of TextBox is also a variable as it stores string values that are typed in the textbox.
The process of creating a variable is known as declaration. Following is an example of declaring and integer variable. The example also includes statement to store a value in the declared variable which is known as assignment. When the variable is assigned a value first time, it is known as initialization.


The above statements can be combined into a single one which is indicated as follows


Variables are also created in classes but when created in classes they are known as properties. For example Microsoft created a variable named Text in class Label which is termed as property of label.
Data Type:
As mentioned that while creating a variable you must mention a data type of that variable. Languages provide data types so that space is effectively utilized and the operations that can be performed are easily identified. The importance of data types is easily understood when it is taken into consideration that in real life the data that is stored has various types, for example salary or price may consist of a decimal point however, age and population do not. In addition to this if you consider age and population age will store a maximum value of probably 150 however population can store an exponentially large value. Therefore it won’t be effective if a language provides a single data type for both age and population. In such case the data type should be large enough to hold population, however when the same data-type will be assigned to age a lot space will be unnecessarily wasted. Therefore Microsoft has provided a range of data types in visual basic.