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.